My rambling thoughts on exploring the .NET framework and related technologies
Home of the surprisingly popular Pixata Custom Controls For Lightswitch (well, it was a surprise to me!)

If you’ve read my recent diatribes, you will be relived to know that this will be a very short post! It wasn’t going to be, but thankfully all the problems I was going to describe have been solved very simply.

Whilst tinkering around with my first Lightswitch application, I wanted to move some code into a separate class library, so it could be reused around the application. Naively, I added a C'# class library to the solution, moved the code over and then couldn’t add a reference to it from my Lightswitch project.

Whilst wondering what was going on, it dawned on me that Lightswitch is really just Silverlight underneath, so needs a Silverlight class library, not a normal .NET class library. I deleted the one I had just created, and added a new Silverlight C# class library. This time, I was able to add a reference and use the code from my Lightswitch application. Phew, one problem solved.

I then decided to write some unit tests for the class. That’s where I ran into the next problem. Normally, I just right-click a method, and choose “Create unit tests” from the context menu. Trouble was, there wasn’t a “Create unit tests” option there.

I spent rather longer than I should trying to work out how to do this, and failed. I even tried adding my own project and making into a test project, but that failed as I couldn’t add references to the appropriate test libraries. This is one of those occasions when you really wonder why Microsoft split Silverlight off from the rest of the .NET framework.

Anyway, the good news is that I just discovered that if you install the Silverlight Toolkit April 2010, you get new Visual Studio templates for unit testing Silverlight applications. They don’t work in quite the same way as normal unit tests, in that the tests themselves run in a Silverlight web application, but the basic principles are the same. You can even use the same code, and the same test attributes as you do in your normal tests.

Apparently, you can even test the UI with this framework, but I haven’t tried that. Needless to say, the fact that I could test my class library was enough to make me happy, and keep this blog post a lot shorter than it would have been - although it’s still a lot longer than it should have been, given the actual amount of useful information it contained! I must learn to be more concise.

Always on the lookout for ways to improve my coding efficiency, I was very interested to hear about WebFormsMvp, which is a framework for writing ASP.NET web sites, based on the MVP design pattern. This post describes my initial frustrations, and eventual delight in using the framework.

In a future post, I intend to describe how to get going with WebFormsMvp, as well as how I extended it to reduce the boilerplate code even more.

Putting reality aside for a moment, and imagining that this blog has at least one avid reader, then he/she may remember that some time ago, I got all excited about ASP.NET Dynamic Data, which looked like a brilliant way to produce CRUD web sites (ideal for the admin back-end of most modern web sites) in almost no time at all. The same avid reader would no doubt also remember that I learnt quite quickly that it was a huge waste of time, great for management demos, but useless for the Real World, and gave up with it.

Well, another day, another new technology from Microsoft, and here we are with very similar promises about being able to produce CRUD web sites in minutes – introducing Microsoft Visual Studio LightSwitch. A moment’s pause over the name will probably reveal the pun on another Microsoft technology, SilverLight. LightSwitch is being promoted as the equivalent for SilverLight that Dynamic Data was for ASP.NET, in other words, a RAD development tool that allows you to produce CRUD sites very quickly.

So, why am I bothering? After all, my previous experience was, shall we say, less than positive! Read more to find out...

I had been having some serious grief with Visual Studio’s unit testing tools. VS was complaining that some tests did not exist, and others called methods that didn’t exist. Both claims were total lies as all methods in question existed, and could be found by using the “Navigate to” feature in VS.

I had two basic errors when I tried to run tests. One was of the form "Method TestProject.SystemsRepositoryTest.CreateNewCamera does not exist" when the method did exist. I could right-click the test in the Test Results window and choose “Open test” and it would take me there. However, when trying to run the test, VS claimed it didn’t exist.

The other error I got was of the form "Test method TestProject.SystemsRepositoryTest.GetAllCameras threw exception: System.MissingMethodException: Method not found: 'System.Collections.ObjectModel.ObservableCollection`1<string> Repository.GetAllCameras()'" which was also a lie as the method being tested existed. Again, I could go to the test method, click on the name of the method being called, click f12 (Navigate to) and be taken to the code for the method.

Thanks to these problems, I have wasted loads of time debugging things that could have been fixed with unit testing. It has been frustrating to say the least!

Well, I finally found the answer…

I opened the bin/Debug folder in the test project in Windows Explorer and deleted everything in it. I then rebuilt the test project, and my tests ran fine.

For some odd reason, it looks like rebuilding the test project wasn't actually changing the DLLs in the folder, so it was using old versions, in which the methods didn't exist. Deleting them all forced VS to grab fresh copies of the referenced DLLs, and rebuild the test project's DLL.

I don’t know if this is a bug in Visual Studio 2010, but it doesn’t seem to be a feature that I would have added in by choice!