Our upgrade to Visual Studio 2010 encountered more problems than we expected. We are developing Silverlight applications for resale using Visual Studio 2008, Silverlight 3 and Blend 3. After doing a little research we devised an upgrade plan to migrate to Visual Studio 2010, .Net 4, and Silverlight 4. Our basic upgrade sequence was correct, but we neglected to include steps for upgrading Nant, Nunit, and Microsoft Patterns and Practices. Also, as of this post, we have not succeeded to get our applications to work on Silverlight 4. I’ve included the upgrade plan we now recommend at the end of this article. In between here and there are the issues we faced with each task and our resolutions.
Visual Studio 2010
I don’t recall any problems with the installation of Visual Studio 2010 or opening our projects and running them there.
.Net 4
We encountered more problems than expected, particularly with the conversion to .Net 4.
Tip 1) When converting projects to .Net 4, start with the projects in the solution that have the most dependencies, such as an .exe. Work your way down toward the dll that has the most dependencies, doing several builds along the way. Check in the changes made so far after each successful build.
Tip 2) Keep an eye on the projects you have changed, particularly if you try to have multiple instances of Visual Studio open. I frequently found that some projects I had converted to .Net 4 lost their changes. This may be because I had two solutions opened at the same time, but each had some of the same dependency projects.
Tip 3) Be careful if you open a Visual Studio command prompt. Make sure you choose a VS 2010 command prompt instead of a VS 2008 command prompt.
Tip 4) In a few cases, the update to .Net 4 did not update some of the referenced system files to their .Net 4 equivalent. Of course, the project won’t compile, and you will need to manually change the reference. This happened to me a few times with the System.Data and System.Data.Extensions DLLs.
Our project files (.csproj) have post-build events in them. Some of the changes we had to make were:
1) To put a file in the GAC, change it from:
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil
to
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil
2) To register an assembly in the post build event, change it from:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe
to
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\regasm.exe
3) and possibly also:
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\tlbexp.exe
to
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\tlbexp.exe
Some of our projects could not compile because they used System.Data.OracleClient which is deprecated in .Net 4. We were able to convert those projects to using the DLLs from Oracle with a few hours of work.
Some of our Visual Basic projects would not compile due to this error:
The error is warning BC42353 or BC42025
“Function ‘IsExcludeField’ doesn’t return a value on all code paths…
Some attributes are deprecated and won’t compile like RegistryPermissionAttribute.
Nant:
Nant’s gac-install was not working for .Net 4, so we converted all of our gac-install tasks to run the gacutil.exe using “exec program” instead. In hindsight, this was not necessary. The real problem was that our modifications to the nant.exe.config file were incorrect. We are now using the nant.exe.config we found at http://pastebin.com/KxqFA8T6
Nunit:
We were running on Nunit 2.4. We realized after the fact that we needed to upgrade to Nunit 2.5.5.10112. I encourage you to upgrade to Nunit 2.5 prior to your upgrade to VS2010. We had a few tests begin failing simply due to differences between Nunit 2.5.5 and 2.4.
We used to run Nunit tests from within Visual Studio by having our nunit test projects launch the Nunit.exe. This option is more complicated now that our application is on .Net 4 because Nunit is a .Net 2 app. It is still possible for Nunit to run tests built in .Net 4, but now, after we launch our application from Visual Studio we need to go back into Visual Studio to the Debug menu, select Attach To Process, and attach to the nunit-agent process in order to debug/step through our nunit tests.
We had to change our nant build process to reference the reference the new directory we installed nunit to and also to specify the correct framework version:
1) <property value=”c:\program files\NUnit 2.4\bin” />
to <property value=”c:\program files\NUnit\bin\net-2.0″ />
2)<property value=”v2.0.50727″ unless=”${property::exists(‘framework.version’)}” />
to <property value=”v4.0.30319″ unless=”${property::exists(‘framework.version’)}” />
3) on commandline for nunit-console:
… /output=mytests.txt /labels
to
… /output=mytests.txt /labels /framework=net-4.0
Managing the GAC
The GAC has changed in .Net 4 and Microsoft has not documented it well (IMHO).
The most (perhaps only) reliable way to manage the GAC on your PC for .Net 4 is the command line tool gacutil. If you open the assembly folder (c:\windows\assembly), you will not see any .Net 4 assemblies, nor is there a .Net 4 Assembly Configuration tool (yet).
I do see that you can open c:\windows\assembly\Download to see your .Net 4 assemblies. But on my machine several of my assemblies are in there multiple times with the same version numbers. And some are marked private and some are marked shared. I don’t know what to make of all of that.
I have gotten good at running this command to dump the GAC contents to a text file which I then open with notepad:
Gacutil /l > c:\gac.txt
Notepad c:\gac.txt
To add a file to the gac I use:
Gacutil /if MyFileName.dll
To remove a file from the gac I use (no .dll extenstion):
Gacutil /u MyFileName
Microsoft Patterns & Practices Logging Framework:
We run one of the programs built on our framework from a network drive. But after our upgrade to .Net 4 this program failed to run from the network drive. We tracked the error down to an inability to load the Microsoft Patterns and Practices (P&P) Logging Framework DLLs. The problem occurred because all the DLLs in our framework use strong name keys, but the P&P DLLs do not. This was not a problem prior to .Net 4; but it is now. Instead of obtaining the P&P source code, adding SNKs, and compiling them ourselves, we obtained the recently released 5.0 version of the P&P DLLs. We had to make a minor code change, and we had to change all of our config files from version 3.1.0.0 to version 5.0.414.0. We also now deploy five P&P DLLs instead of the three we needed in the previous version of P&P.
Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
to
Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Silverlight 4
I recommend that developers avoid installing the Silverlight 4 runtime until after they are on VS2010. I upgraded one machine to the Silverlight 4 runtime and then was no longer able to debug my Silverlight 3 application in VS2008.
At this time, we have not successfully converted to Silverlight 4.
When you convert to Silverlight 4, it is best to convert all the projects in the solution to Silverlight 4 at the same time. In a few cases, Visual Studio did not correctly upgrade the System Dlls and we had to unreferenced them, then re-reference them. Our application uses the Csla.net framework. We experienced a problem when running our app and the problem only occurs in release mode. Apparently Silverlight 4 release mode optimizes the data sent down to the client such that our serialized values don’t all make it to the client. We tried upgrading from Csla 3.8 to Csla 3.8.3; and we also tried converting all of our private static propertyinfo methods in our business objects to be public. This latter action did cause our application to get past several errors, but the application still fails to return all the data to the client in release mode most of the time. We are still working on resolving this.
If we were to do our upgrade again, this would be our conversion plan:
1) Upgrade to Nant 2.5 and upgrade your config files for Nant to support .Net 4 (http://pastebin.com/KxqFA8T6). Test build processes.
2) Upgrade to the most current version of the Microsoft Patterns & Practices Logging Framework. For us, version 5.0.414.0 (http://entlib.codeplex.com). Test build processes and deployed application from build.
3) Upgrade to the most current version of Nunit (http://nunit.org). Run all tests.
4) Upgrade one developer to Visual Studio 2010.
5) That developer should convert all projects and solutions to VS 2010 and test them.
6) Upgrade all other developers to Visual Studio 2010.
7) Upgrade the build server to Visual Studio 2010, convert all the projects and solutions on the build server to VS 2010, and test the build process. Check in all changes to the subversion repository. Developers update from subversion.
8 ) Have one developer upgrade all projects to .Net 4 and test.
9) Make changes to build processes for .Net 4, build, deploy, and test.
10) All developers update from subversion to get .Net 4 versions of projects.
11) Have one developer upgrade to Silverlight 4 and test. Make sure to test with Release mode compiles!
12) Make changes to build processes for Silverlight 4. I don’t think we had any.
13) All developers update to Silverlight 4.