2 comments
.NET 
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?
2 comments
Proposed workaround #1 for the keyfile-problem: <br />"Edit the project file with a text editor. Change the path to the shared file, for example ….keys.snk. The build process will work fine, there will not be a local copy made of the file, BUT the VisualStudio GUI shows blank for the filename"<br /><br />Workaround #2:<br />[1] Right click on the root folder of the project and select "Add Existing Item"<br />[2] Browse to the .snk file in the Open File dialog<br />[3] Click on the down-arrow on the button that says "Add" and choose "Add Link"<br /><br />However, I still think it’s lame to state "It’s a lot easier to manage your SCC state, etc. if everything in the project is under a project cone". What’s wrong with making it the programmers responsibility to make sure the keyfile or other files referenced by the project (but outside the projects’ folder) are stored in the source repository?
robert.te.kaat@gmail.com (Robert te Kaat)
My proposed solution for the keyfile problem is, don’t use it!
Instead use the AssemblyKeyName attribute. With sn.exe you can register the keyfile on every developer box under a "name". Then in the AssemblyKeyName attribute you can refer to this common name. So every developer can decide by himself where the file is stored (only once!).
Dennis Mulder