Kristof Rennen’s Blog

The last few days have been great for the Microsoft Surface in belgium.

Last sunday, VTM used a Microsoft Surface during the election show, to visualize the results.
You can read more details in my previous posts:

• VTM Goes Surface
• Microsoft Surface At The Belgian Elections

On monday VTM already launched its second surface application:

This application is used to browse and manipulate belgian newspapers and magazines during the late news.
In the following weeks / months, this will be a fixed item in the late news to show the headlines of the next day in the same format as the real printed papers.

With those 2 applications, VTM really gave the surface a great start in Belgium. Let’s hope a lot of great application will follow in the future.

Kristof Rennen Development Microsoft, Surface

In my previous post I already mentioned VTM using a Microsoft Surface to give an overview of the 2009 election results.

There is already a video available, posted by Luc Van de Velde of Microsoft:

Kristof Rennen Development Microsoft, Surface

Yesterday, elections took place in Belgium.
As with any election show, TV stations always do their best to impress people watching as much as they can.

VTM chose to use the Microsoft Surface during their show as the first one in belgium using this new technology for a real purpose.

The application itself consisted of 3 scenes used by the presenter to go through the results as they were gathered throughout the day:

• A startup scene
• A coalition scene
• An evolution scene

The startup scene

The startup screen showed the logo of “De Stem Van Vlaanderen”, the same one as used on the plasma screens behind the presenters.

The coalition scene

This scene was used to navigate through all the possible coalition combinations between the 7 big factions.

An overview of all factions is shown, which can be expanded or collapsed showing the total number of seats reached by that faction.

By dragging the faction itself into a pie, 3D pie pieces visualize the possible coalitions.

The evolution scene

This scene is used to show the evolution of factions and cartels between the elections of 2004, 2007 and 2009.

By dragging the title of the faction into the bar below, the results of that faction are shown.

By using different discs the results from all the factions could be visualized in an interactive fashion.

This shows us how nicely a Surface can be integrated into any environment, and according to me the application really looks nice so they gain my vote

Let’s hope they will come up with various nice applications in the future.

Kristof Rennen Development Microsoft, Multi-Touch, Surface

In my previous article, I talked a little about the inside and outside of a Microsoft Surface unit. To actually start developing Surface applications, a few more steps are required.

Prerequisites

• Microsoft .NET Framework 3.5
• Microsoft Visual Studio 2008 with C# Project features
• Microsoft Windows Vista 32 bit
• Microsoft XNA Framework Redistributable 2.0 (available here)
• Microsoft Surface Development Kit (not publicly available)
• A minimum screen resolution of 1280 x 960

Creating projects

After the installation of the prerequisites is done, extra templates have been added to Visual Studio to be able to create new Surface projects.

There are 2 options to create a new Surface project:

• Using WPF
• Using XNA

I will be choosing WPF now, so when the new project is created a basic structure is foreseen which looks like this:

Following files are already available:

• A first surface window
• An app.xaml to initialize the application
• An application xml file to describe the application (description, name and icons)
• Some resources

Running projects

There are 3 possibilities to run a Surface application:

• As a standard windows/wpf executable
• On a Surface unit itself
• Inside the Surface simulator

Any Surface application can be started as any regular wpf/windows application by double clicking on the executable, or by hitting F5 inside Visual Studio.

The application will then look like this:

The second way of running a surface application, is by running it on a surface unit or inside the surface simulator.

Surface Simulator

The surface simulator is an application installed when you install the Surface sdk. It simulates a multi touch device, by supporting multiple mice, tags, … anything which is supported by a real Surface unit.

The simulator can be found here:
C:\Program Files\Microsoft SDKs\Surface\v1.0\Tools\Simulator\SurfaceSimulator.exe

When multiple mice are attached to the computer, they can all be used to interact with the application although working with multiple mice on a single computer is not really easy

If you are like me running on a screen resolution less than 1280 x 960, you will receive following error message unable to run the simulator. I’m going to try to find a solution for this so I can develop surface application on my laptop as well.

To run the application inside the simulator, you have to make sure the simulator is running before you start the application. When the simulator is running, and you start the application using the executable or by hitting F5 inside visual studio, the simulator will show the application:

Conclusion

Now that we have our environment set up, we can start developing our kick ass Surface applications. The development itself is more or less the same as WPF development. Only a few controls have a specific Surface control which needs to be used (SurfaceButton, SurfaceCheckbox, SurfaceWindow, …)

An important tip when starting with surface development is not only relying on the simulator to test the applications. It’s really needed to test the application properly on a real unit as well since the interaction with multiple people around the application is a lot different than running it on a single machine with multiple mice.

In the coming weeks I will be posting a little more on my experiences while developing one of our Surface applications, so stay tuned.

Kristof Rennen Development Microsoft, Multi-Touch, Surface

A few years ago, when I started doing Test Driven Development, the defacto .NET standard was NUnit. Ever since I’m using the NUnit framework to do my testing.

Even though there are many other frameworks (like MbUnit) with lots of cool features NUnit is missing, some neat stuff can be done using NUnit as well.

In this article I’m going to show some basic and advanced usages of SetUp and TearDown possibilities of the NUnit framework.

SetUp

The SetUp is the method executed before every test, which can be used to prepare the state of the system you are going go test.

TearDown

The TearDown is the method executed after every test, which can be used to restore the state of the system you have tested.

The important keywords here are “every test”.

One of the basic rules of Test Driven Development is that tests need to be fast. Only when tests run fast, they will be executed a lot so you can depend on the results to know that everything is working correctly.

Since logic inside SetUp and TearDown will be executed for every test, this can cause tests to become slow (certainly when you are doing a lot of database access, which is not the scope of this article).

NUnit has a solution for this, and supports TestFixture SetUps and TearDowns and even Namespace / Assembly SetUps and TearDowns (sounds nice hu?).

Assembly SetUp / TearDown

In some cases it might be handy to have some SetUp and TearDown code which will be executed once for each assembly containing your precious tests.

To enable this feature, you just add a TestClass to the root of your assembly (root namespace), and mark it with the correct attributes.

The following requirements need to be fulfilled to have it working:

• The class must be in the root namespace (root of the assembly)
• The class must be marked with the [SetUpFixture] attribute
• A public default contructor needs to be available to make sure NUnit can make an instance
• The AssemblySetUp method must be marked with the [SetUp] attribute
• The AssemblyTearDown method must be marked with the [TearDown] attribute

Namespace SetUp / TearDown

The same priciple as with the Assembly SetUp and TearDown can be applied for each Namespace inside a TestAssembly. Just add the same class to a namespace root, and it will be executed once for that namespace.

The following requirements need to be fulfilled to have it working:

• The class must be in the root of the namespace
• The class must be marked with the [SetUpFixture] attribute
• A public default contructor needs to be available to make sure NUnit can make an instance
• The NamespaceSetUp method must be marked with the [SetUp] attribute
• The NamespaceTearDown method must be marked with the [TearDown] attribute

Fixture SetUp / TearDown

For every test fixture (test class), a one time SetUp and TearDown can be added as well. Those will be executed once before and after all tests in the same class.

The following requirements need to be fulfilled to have it working:

• The class must be marked with the [TestFixture] attribute
• The ClassSetUp must be marked with the [TestFixtureSetUp] attribute
• The ClassTearDown must be marked with the [TestFixtureTearDown] attribute

Test SetUp / TearDown

The default SetUp and TearDown as described above will be executed before and after every test.

The full structure of the project looks like this:

A final test class, with all features included as described above, can look like this:

When executing all tests in the assembly using the NUnit Gui, we can see the following output printed out on the console:

The following conclusions can be made based on the result above:

• The AssemblySetUp is executed once at the beginning of the full assembly
• The AssemblyTearDown is executed once at the end of the full assembly
• The NamespaceSetUp is executed once at the beginning of the full namespace
• The NamespaceTearDown is executed once at the end of the full namespace
• The ClassSetUp is executed once at the beginning of the full class
• The ClassTearDown is executed once at the end of the full class
• The SetUp is executed at the beginning of each test
• The TearDown is executed at the end of each test

This was an introduction to some more advanced SetUp and TearDown possibilities of NUnit. Using it in a real project depends on your specific needs, but the above can be used as a good starting point if you’ll ever need it.

Kristof Rennen Development .NET, NUnit, TDD, Test-Driven

In my two previous posts, How An ASP.NET DataBind Can Cause A Memory Leak and How An ASP.NET PostBack Can Cause A Memory Leak, I showed you how a UserControl inside a Repeater could cause serious memory problems.

Well after working on the memory issues for several days already, a co-worker of mine finally found a solution to ensure all user controls and pages are disposed properly.

Davy explains how he solved our problems in his blog post about the topic: Guaranteeing Disposal Of UserControls In ASP.NET

 Well, thanks to Davy’s great technical knowledge, we finally managed to get the memory in this application and all our future applications stable, proven by a rerun of our stress test scenarios.

Thanks Davy!!

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling

In my previous post How An ASP.NET DataBind Can Cause A Memory Leak, I talked about how I suffered from serious memory leaks in my current project, because of some user control not being disposed when doing manual databinding multiple times.

After being really happy about my tedious quest being finished to fix the problems, I today noticed the memory leak still occurred in exact the same location, but when using the functionalitity in another way.

The case is still the same:
Page -> UserControl -> Repeater -> UserControl

So the loaded page of the scenario, contained a user control of our own. This user control had a repeater, repeating over the rows of a generic list, creating another UserControl for each found row.

Every row, rendered through the ASP.NET Repeater, has 2 buttons available:

• A button to edit the given row
• A button to delete the given row

The button to edit the given row is not giving me any problems. When I click it, the user gets redirected to the edit page and everything gets cleaned up pretty well.

The delete button on the other hand, is performing a postback on the same page, calling an event to handle the delete:

Ofcourse this delete event is doing the following stuff:

• Getting the row’s id from the CommandArgument
• Calling our business layer to delete the record
• Performing a databind to reflect the changes

It is the last action, which performs the databind, which is now triggering the memory leak … again.

The problem

By doing a postback when clicking the button, a new instance of my user control with all it’s needed resources is created.
Because I’m doing a DataBind() at the end of my “Action”, a second instance of the same user control with all it’s resources is created, leaving the first one undisposed forever.

The second one though, is being disposed properly and does not give me any problems.

The only explanation I would have for this kind of behaviour, is that it all happens inside one postback cycle.
Probably if a control is then created multiple times, only the last one gets disposed at the end of the cycle, leaving the other ones up to the Garbage Collector.

In our case the Garbage Collector is not of any use, since the user control has references to other undiposed objects, causing all those objects to remain in memory and causing a memory leak in the end.

The solution

Well, to be honest I don’t know a proper solution right now and I will probably need some time to figure out a proper way to fix this.

If I add the databind, the application is suffering from a memory leak, which is totally unacceptable.
If I remove the databind, deleted records are still shown on my page, which is totally user unfriendly.

I’ll keep you posted if I find a proper solution, and I then hope ASP.NET is not going to disappoint me ever gain.

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling

Currently I’m working on an ASP.NET application for one of our customers. The application is nearly finished, and is going to be put in acceptance and production in a few weeks.

To test the scalability of the application, stress and load tests are run using Visual Studio Team Test at our side and Load Runner at the customers side.

The stress tests are all running well on both sides, except for some weird OutOfMemory exceptions after a run of 9 or 10 hours with 100 concurrent users. The scenarios are built to simulate one month of work in 10 hours.

Setting up the environment

Since the application consists of a front end and backend, it was important for me to setup my IIS properly to enable me to find whether the problem was caused in the backend or frontend.

The backend application, is a WCF service host, running inside IIS. The frontend application is an ASP.NET application consuming the backend through WCF services.

The running both the service host and web application in a separate application pool, I was able to monitor both separate worker processes to narrow down the problem to one of the two.

Finding the cause of the OutOfMemory exceptions

Before one can start fixing the cause of the OutOfMemory exceptions, you first have to find the cause of course.

Using windbg, DebugDiag and DotTrace, we started investigating the memory usage and patterns of the applications finding that the allocated virtual memory was exceeding the IIS limit, causing OutOfMemory exceptions and unexpected pool recycling.

It was clear the application was suffering from a memory leak, which could still be a native or a managed leak.

A great source to find more information on tracing, Windbg, … is the blog of Tess Ferrandez, an ASP.NET Escalation Engineer of Microsoft. Her blog really helped me out during my search for the cause of memory leaks, and by analyzing all the memory dumps I created.

Reproducing the memory leak

Before one can start fixing the memory leak, its best to have a scenario to easily reproduce the problem.

We started by creating a scenario using a lot of functionalities from the application. By running this scenario we could easily reproduce the problem after a run of a few hours.

By narrowing the scenario down, up to a single functionality only, I was able to trigger the high memory usage faster and find the location of the bottleneck in the application.

I now had an easy way to reproduce the problem, and to verify the fix afterwards.

Tracing the memory usage

Since I now had a scenario which I could use to trigger the memory leak, I used JetBrains’ DotTrace profile to profile my IIS while running the scenario.

Everytime I ran the scenario, I noticed some ASP.NET UserControl not being released from memory. Since this user control, had references to other components as well, those components were “leaked” as well.

By using the trace output, I now had the name of the user control which was not being disposed properly.

The actual problem

The actual problem was a page containing a user control with the following structure.

Page -> UserControl -> Repeater -> UserControl

So the loaded page of the scenario, contained a user control of our own. This user control had a repeater, repeating over the rows of a generic list, creating another UserControl for each found row.

Since we are using ASP.NET with the Model-View-Presenter pattern (to be able to develop everything Test-Driven), we were calling the databind of the view manually as follows:

First we DataBind() the user control after its properties have been set. Then we call base.DataBind() which does a DataBind() of the complete page.
Ofcourse the DataBind() of the usercontrol is not really needed since it will be automatically called when you DataBind the complete page, but hey it should not cause any problems either.

Since the memory profile told us the user control was not properly cleaned up, we just put a breakpoint in its constructor and dispose method.
Analyzing this really blew us of our seats. The constructor of the user control was called twice, but the dispose method was only called once so we were stuck with one instance of the user control for ever. Hello Memory Leak!

The solution

Solving the memory leak was in the end easier than we should have imagined. By just removing the UserControl.DataBind() did the trick.

The DataBind() of the page now looks like this:

Conclusion

I ran my stress tests again together with my DotTrace profiler and everything seemed to be working ok. The memory leak was fixed, and the memory usage of the application was back to normal.

Currently a new run of the stress tests are both running on our environment and our customer’s, but I’m really confident the memory leak was fixed.

Now that I had this memory leak by just using functionalities from ASP.NET, I’m not sure if it is like this by design or that it is really a problem in ASP.NET itself? I hope to find an answer soon, but in the meanwhile I call it dirty behaviour of ASP.NET itself ;-).

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling

Great news for the Silverlight fans out there since Microsoft already released the first beta of Silverlight 3 at MIX09.
Its a preview release which continues Silverlight’s track record of rapid innovation, introducing 50+ new features.

Some of the nice new features include:

• Support for higher quality audio and video (more formats, 720p+ streaming, HD, content protection, …)
• Empowering richer experiences (animation effects, enhanced control skinning, perspective 3D, …)
• Improving RIA productivity (60+ controls with source, Search Engine Optimization, improved performance, …)
• Out of the browser capabilities (life outside the browser, shortcuts, auto-update, …)

Together with this beta release of Silverlight 3, Microsoft also released a first preview of Expression Blend 3.

More information can be found on the official Silverlight website.
The windows developer runtime can be downloaded from Microsoft’s site.

Kristof Rennen Development .NET, Blend, Expression, Microsoft, MIX, Silverlight

Yesterday Microsoft released version 1.0 of its ASP.NET MVC framework.
It finally is production ready, supported and lets hope stable.

I don’t have any experience yet with this new technology, but I’m sure I’m going to check it out somewhere between today and a few weeks.

I will use this opportunity to finally create a proper website for my band Jessie’s Five.
The current version of the website is a temporary one, containing all information but in an ugly shell using static ASP.NET.
The new version of the website will be dynamic and containing an Administration section.
The other band members will be able to update the site themselves, resulting in a more updated site and me not forgetting to do it anymore.

I hope my host Mochahost will support the MVC framework soon, so I can start using it.

For more information on the ASP.NET MVC Framework: http://www.asp.net/mvc/
Version 1.0 can be downloaded from Microsoft’s site.

Kristof Rennen Development .NET, ASP.NET, Jessie's Five, Microsoft, MVC