Archive

Archive for April, 2009

A Brief Look At The Microsoft Surface

April 22nd, 2009
9 comments

As of today, we are working on a Microsoft Surface application which gave me the idea starting to blog about news, features, nice to knows, … anything you may want to know about the Microsoft Surface and the development of Surface applications.

In this first article, I will be talking about the Surface in general, and what it is all about.

The Idea

Microsoft Surface fundamentally changes the way we deal with digital content on a computer.

Instead of working with a dull mouse and keyboard, which is not very intuitive to all users, we will be using our hands and fingers to operate the Microsoft Surface.

We can grab data with our hands, move it around by performing simple gestures, and this even with multiple persons simultaneously.

All computers only have a single input device which is the mouse. The surface on the other hand is a full multi-touch device, supporting up to 52 touch points (that are a lot of mouses).

The Outside

The Surface itself it built as a small table, where the plate itself is the multi touch device.

Because it looks so natural, it can easily be included in various surroundings.

Microsoft Surface: The Outside

The surface of the Surface, is a kind of matted glass material, feeling really soft to the fingers, and allowing fast movement.

The viewing angle and brilliancy of the screen is made so a lot of users can have a clean image, when surrounding the table.

The Inside

Microsoft Surface: The Inside

The inside of consists of 3 major parts:

  • Near infrared camera’s
  • A computer
  • Rear projection system

In total, there are 5 camera’s monitoring the surface for movement tracking. The reason Microsoft uses 5 camera’s, is to solve field angle problems. Each camera monitors it’s own small area of the surface, resulting in better speed and resolution. It was also needed to get the table as low as it is now.

The camera’s themselves can read unlimited numbers of touch points on the surface. The limit of 52 is only set because of CPU processing limits.

The computer inside the Surface is a high-end machine, but runs on mainly conventional components. It is powered by a Core 2 Duo 2.13 Ghz CPU, and has 2GB of RAM.

The Operating System on the surface computer, is a standard non-modified Microsoft Windows Vista operating system. An extra layer is running on top of this windows vista, called the shell.

The read projection system, projects the computer’s image to the underside of the tabletop.

Communication

The Surface offer 3 ways of communication:

  • WiFi
  • Ethernet
  • Bluetooth

There are already sample application using the WiFi possibilities to automatically load content from a wireless device, if put on the Surface.

Development

To develop Surface application, there is a choice between Windows Presentation Foundation and XNA. Custom WPF control have been built to support the Surface specific interactivity.

The development can be done using the Microsoft Surface SDK, which integrates with Visual Studio 2008 and allows the developers to run a Surface Simulator to test the application locally on a windows vista machine.

Technical Specifications

Size: 108 x 69 x 54 CM
Weight: ca 90kg

Network:

  • IEEE802.11b
  • IEEE802.11g
  • Bluetooth 2.0
  • Gigabit Intel Network Adapter

I/O:

  • 2 headphone jacks
  • 6 USB 2.0 ports
  • RGB component video
  • S-VGA video (DB15 external VGA connector)
  • Component audio
  • Ethernet port (Gigabit Ethernet card [10/100/1000])
  • External monitor port
  • Bays for routing cables
  • On/Standby power button

 Display:

  • Type: 30-inch XGA DLP® projector
  • ATI X1650 graphics card with 256 MB of memory
  • Maximum resolution: 1024 x 768
  • Lamp mean-life expectancy: 6,000+ hours

Computing System:

  • 2.13-GHz Intel® CoreTM 2 Duo processor
  • Memory: 2 GB dual-channel DDR2
  • Storage: Minimum 250 GB SATA hard-disk drive

More Information

More information can be found at the following locations:

In one of my coming articles, I will be talking about Microsoft Surface Development.

Kristof Rennen Hardware , , ,

Getting The Most Out Of NUnit’s SetUp And TearDown

April 13th, 2009
2 comments

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.

    1         [SetUp]

    2         public void SetUp()

    3         {

    4             Console.WriteLine(“\t\t\tTest SetUp”);

    5         }


TearDown

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

    1         [TearDown]

    2         public void TearDown()

    3         {

    4             Console.WriteLine(“\t\t\tTest TearDown”);

    5         }


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.

    1 namespace DotNet.NUnit

    2 {

    3     [SetUpFixture]

    4     public class AssemblyFixture

    5     {

    6         public AssemblyFixture() { }

    7 

    8         [SetUp]

    9         public void AssemblySetUp()

   10         {

   11             Console.WriteLine(“Assembly SetUp”);

   12         }

   13 

   14         [TearDown]

   15         public void AssemblyTearDown()

   16         {

   17             Console.WriteLine(“Assembly TearDown”);

   18         }

   19     }

   20 }


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.

    1 namespace DotNet.NUnit.Namespace1

    2 {

    3     [SetUpFixture]

    4     public class NamespaceFixture

    5     {

    6         public NamespaceFixture() { }

    7 

    8         [SetUp]

    9         public void NamespaceSetUp()

   10         {

   11             Console.WriteLine(“\tNamespace 1 SetUp”);

   12         }

   13 

   14         [TearDown]

   15         public void NamespaceTearDown()

   16         {

   17             Console.WriteLine(“\tNamespace 1 TearDown”);

   18         }

   19     }

   20 }


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.

    1 namespace DotNet.NUnit.Namespace1

    2 {

    3     [TestFixture]

    4     public class ClassFixture

    5     {

    6         [TestFixtureSetUp]

    7         public void ClassSetUp()

    8         {

    9             Console.WriteLine(“\t\tClass 1 SetUp”);

   10         }

   11 

   12         [TestFixtureTearDown]

   13         public void ClassTearDown()

   14         {

   15             Console.WriteLine(“\t\tClass 1 TearDown”);

   16         }

   17     }

   18 } 

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.

    1         [SetUp]

    2         public void SetUp()

    3         {

    4             Console.WriteLine(“\t\t\tTest SetUp”);

    5         }

    6 

    7         [TearDown]

    8         public void TearDown()

    9         {

   10             Console.WriteLine(“\t\t\tTest TearDown”);

   11         }

 

The full structure of the project looks like this:

DotNet NUnit Solution

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

    1 namespace DotNet.NUnit.Namespace1

    2 {

    3     [TestFixture]

    4     public class ClassFixture

    5     {

    6         [TestFixtureSetUp]

    7         public void ClassSetUp()

    8         {

    9             Console.WriteLine(“\t\tClass 1 SetUp”);

   10         }

   11 

   12         [SetUp]

   13         public void SetUp()

   14         {

   15             Console.WriteLine(“\t\t\tTest SetUp”);

   16         }

   17 

   18         [TestFixtureTearDown]

   19         public void ClassTearDown()

   20         {

   21             Console.WriteLine(“\t\tClass 1 TearDown”);

   22         }

   23 

   24         [TearDown]

   25         public void TearDown()

   26         {

   27             Console.WriteLine(“\t\t\tTest TearDown”);

   28         }

   29 

   30         [Test]

   31         public void Test1()

   32         {

   33             Console.WriteLine(“\t\t\t\tClass 1 - Test 1″);

   34         }

   35 

   36         [Test]

   37         public void Test2()

   38         {

   39             Console.WriteLine(“\t\t\t\tClass 1 - Test 2″);

   40         }

   41     }

   42 }


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

DotNet NUnit Gui

DotNet NUnit Output

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 , , ,

Getting Your ASP.NET UserControl Disposed … At All Times

April 9th, 2009
1 comment

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 , , , ,

How An ASP.NET PostBack Can Cause A Memory Leak

April 8th, 2009
1 comment

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:

    1         public void DeleteImageButton_Click(object sender, EventArgs e)

    2         {

    3         }

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 , , , ,

How An ASP.NET DataBind Can Cause A Memory Leak

April 6th, 2009
1 comment

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:

    1         public override void DataBind()

    2         {

    3             //Set some UserControl properties here

    4             UserControl.DataBind();

    5 

    6             base.DataBind();

    7         }


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:

    1         public override void DataBind()

    2         {

    3             //Set some UserControl properties here

    4 

    5             base.DataBind();

    6         }


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 , , , ,