Interesting observations porting a library to .Net framework 2.0.

Today I have done some impact analysis on converting a pretty large library used at a customer of mine. During this impact analysis I decided to just import the project into Visual Studio 2005 and see what happens.

 

While converting the project I came across two interesting things that I think is worth blogging about. The first is that we use a lot of configuration section handlers in the library to make everything as pluggable and configurable as possible. One of the API’s that is marked as obsolete is the System.configuration.ConfigurationSettings.GetConfig(string). You should replace the method call with a call to System.Configuration.ConfigurationManager.GetSection(). While this is no problem, I noticed I would not get any help from the IDE when I typed the proposed solution. At first I was puzzled but I found that the new implementation now resides in a other assembly as well that I did not reference previously. The old API resides in the System assembly while the later resides in the assembly System.configuration.

 

The second thing I ran into was a little bit more annoying and I think this is a flaw in VS.NET 2005. (b.t.w. I am using the RC1 of VS.Net 2005 now)

The compiler gave me a warning that the strong name key file attribute : [assembly: AssemblyKeyFile(“….mykey.snk”)] is also obsolete. They suggest you need to change your project settings so it will include a command line for the compiler that refers the keyfile. Ok I can live with that, but now the IDE does something I can not understand. When you select a keyfile in your solution (most of the time a snk file that is placed at a shared location e.g. in the Solution Items folder) it will copy the keyfile to your local project directory! This is realy a big problem. This means you will have a copy of your keyfile for every project you will have. How can I e.g. now use a separate key file for development and change it for release? And how can I at least make sure they are all the same file? With Team Foundation source control in the near future you will be toast, because the sharing feature is not available (and I agree that you should not need). The only solution I have now is to use the new #pragma keyword to disable the warning for the obsolete assembly keyfile attribute.

 

I did some digging in the Microsoft assemblies and what really is astonishing is that they still use the attributes themselves! Take e.g. a look at the metadata of the system.configuration assembly. You will see they use delay signing and a public keypair on the drive f:RTMToolsDevDivFinalPublicKey.snk

 

I filed a bug report on this and I hope you will vote for this if you think this is a Bug as well. Or enlighten me, why this would be a good thing?