Adventures while building a Silverlight Enterprise application part #15

This was one of these weeks. You know, a week that gets hectic unexpectedly? Last Tuesday-night we had a company meeting as we have every three months. Some of the major topics inside the company are presented to the entire staff. This varies from finances to important projects and new customers. One of the topics was the new version of our system on which I was to be giving a short demo.

Not so much of a problem until I decided to publish the latest standing of the Silverlight client to my local IIS on Tuesday-afternoon, with only about 30 minutes to go until the start of the meeting.
I know, I shouldn't be doing that so short before a demo, but I spend the days before that drastically improving the layout of the application, together with one of our product-experts and we decided, this being an internal presentation and all, that it was important to give a positive impression to the staff with this new and improved interface. I got a 'Publish succeeded' from Visual Studio so I fired up Internet Explorer and surfed to my local site, hosting the Silverlight client. I saw the first peaces of the application come up and then, all of a sudden, it threw an exception...

As I now had only 25 minutes left, I was in a tight spot. I decided to use my time to go over the demo from Visual Studio, to make sure everything worked nicely in there. After that, with only 10 minutes left, I decided I would demo from Visual Studio, as there was no time to actually troubleshoot the IIS deployment.

I don't think anyone noticed, or even cared for that matter, but I personally hate doing demos from Visual Studio. You always run the risk of running into some forgotten break point or that exception that you did catch still stops in the IDE. You could run in all sorts of problems.

After that I was busy for the past days, rebuilding some of the code generation we use for our business objects, so they would now use CodeDom, instead of a StringBuilder, so I had no time to troubleshoot the IIS deployment process untill today, when I had too, because this afternoon we want to update our test environment.

I tried attaching Visual Studio to iexplore.exe to see if I could debug my code this way, but none of my breakpoints would trip (altough Visual Studio did catch the JavaScript exception that is thrown when something isn't catched in Silverlight). This made it a lot more difficult to find out where things went wrong. Fortunately we load several .xap files on the fly, so I opened up HttpWatch and recorded the traffic while reloading the application. I did several runs and found out that the problem was always with loading one particular .xap file.
At first I thought it may be because an older version would be loaded from cache, as loading the .xap file would trigger a HTTP 304, meaning a version was loaded from cache. Clearing out the cache, however, didn't resolve the problem.
I was on to something however. I republished my solution to IIS, cleared the cache and tried again. This time I did get a HTTP 200, meaning that the .xap file was loaded OK, but I still got an exception. I opened up the ClientBin folder containing the .xap files for my IIS deployment and looked at the filedates.
It turned out that some of my .xap files were actually not updated recently! As I did make changes to assemblies that these .xap files use, surely they crashed. I went into Visual Studio again and published once again, this time specifying that any files should be deleted from the folder first.
I refreshed the application in Internet Explorer and suddenly it all workes nicely.

So some lessons learned:

• Take more time before a presentation to make sure everything works
• Don't trust Visual Studio to know when files need updating
• Completely redeploy your applications every now and then

I hope you may prevent these pitfalls because you read them here first.

P.S.: For everyone wondering about the CodeEmbed4Web tool, the code is pretty much done, just some organizational stuff to be taken care off.