0 comments
.NET 
As of today I’m one of the guys that had to face the upgrading process from silverlight 2.0 to silverlight 3.0 with a nightly build. It was a special kind of experience, because appearantly what was supposed to be a smooth switch turned out to be a whole day of trial and error with a successful migration at the end of that day.
A shoppinglist
You will need a couple of things to move from Silverlight 2.0 to Silverlight 3.0 below is a short shopping list for developers wanting to migrate:
- The Silverlight tools v3: http://www.microsoft.com/downloads/details.aspx?familyid=9442b0f2-7465-417a-88f3-5e7b5409e9dd&displaylang=en
- A hotfix for visual studio: https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=16827&wa=wsignin1.0
The hotfix is a must have, because after upgrading I found that visual studio drops dead when compiling a Silverlight project or debugging an already compiled Silverlight project. It does so with a very descriptive “Fatal Execution Engine Exception” (At least it has an errorcode :P).
Warning: Be sure to check if third party control libraries are supported before starting the migration process. The whole migration process can take between 1 hour and 8 hours to complete, depending on how many projects you need to migrate and the speed of your machine/internet connection.
The upgrade procedure
Luckely the migration procedure is not that hard. It mostly involves uninstalling old stuff and installing the software from the shoppinglist. There are however some specifics that every developer must know to get things working the first time ’round.
Step 1: Uninstall the Silverlight 2.0 SDK, Silverlight 2.0 tools for VS2008 SP1 and Silverlight(!), this ensures on most occasions that your computer is clean and good to go for the new Silverlight framework.
Step 2: Clean out C:Program FilesMicrosoft sdksSilverlightv2.0 and C:Program FilesMicrosoft Silverlightv2.0.xxx. This part is only necessary when the uninstallers fails silently and leaves parts of the Silverlight installation behind on your machine.
Step 3: Install the new Silverlight 3.0 tools on your machine. Nothing fancy here, just follow the steps on your screen and it should install the new tools including the SDK and a fresh Silverlight 3.0 runtime with debug symbols. Only developers get these through the installation package, users won’t get debug symbols, so their download is much smaller.
Step 4: Install NDP20SP2-KB963676-x86.exe on x86 machines or NDP20SP2-KB963676-x64.exe on x64 machines to fix the fatal executing engine exception problem.
Step 5: Install Windows6.0-KB963676-x86.msu on x86 machines or Windows6.0-KB963676-x64.msu on x64 machines. This additional patch should further improve behavior of windows in combination with Visual Studio 2008 SP1. I’ve noticed that not all machines need this patch, so there’s no problem if the installer tells you it doesn’t apply to your machine.
Step 6: The windows update should ask you to reboot, but in case the update doesn’t apply or you don’t get the message dialog for the reboot I advice developers to reboot their machine after this upgrade.
Migrating Silverlight projects
After upgrading your machine it’s time to upgrade the Silverlight solutions. For this you only need to open the Silverlight solution in Visual Studio and Press Ctrl+Shift+B to rebuild the solution. Check for leaky spots (a.k.a compile errors) and run the project to make sure that everything runs ok.
It’s important to notice here that there might be third-party controls that aren’t supported yet by Silverlight 3.0. I had this with Telerik, but using the latest build solved my problem.
Conclusion
By migrating our projects to Silverlight 3.0 we added some great new features to our frontend solution in terms of validation and theming. But we also solved quite a lot of warnings in the build and some rather nasty bugs in the runtime. And in the end the migration of the Silverlight projects only took us half a day. The rest of the day we were busy verifying our team build and cleaning up some misc. problems we encountered.
By writing this article I hope to save other developers a load more time, so that migration should be not more than uninstalling the old and installing the new on developer machines.