Daniel Moth questioned the move from source attribute to project properties. Here’s my insight on 2 of the reasons. First the disclaimer:
This posting is provided “AS IS” with no warranties, and confers no rights. The content of this posting contains my own personal opinions and does not represent my employer’s view in anyway.
The 2 reasons I was aware of fell into 2 categories: security and usability. First of all you have to remember that the Assembly level attributes are embedded into your assembly. Thus the final assembly that you shipped contained all the information in those attributes. Thus the filename of your key is shipped out to all of your customers. The security gurus decided this was too much information; even with the mitigating factor of delay signing (meaning, hopefully, the file only had your public key and the private key was stored someplace really secret). Especially if you put a fully qualified path to the key file that might contain other sensitive information like your username, project code name, machine name, etc. Next comes usability. Anybody coming from C/C++ is familiar with mucking with the include file path to get their #include directives to work, especially when it included partial paths. Due to an implementation detail the tool that processed the AssemblyKeyFileAttribute was not the compiler itself, but another tool invoked by the compiler. That tool was not aware of the location of the attribute in source, so it could not give as useful error messages. For the same reason it could not do a source-relative search for the file when given a partial path or filename. Instead it searched in 2 places: output file relative and current-directory relative. The output file relative was confusing (do you remember when everybody put “..\\..\\mykey.snk”?) not only because it was 2 directories down, but because for C# it was really the intermediate file location (obj\Debug instead of bin\Debug as most would expect). The current directory was problematic because it kept changing. For a command-line compiler like csc.exe it was logical and made sense. But for a multi-threaded GUI app like devenv.exe it was a lost concept. People would complain that sometimes their project would compile and sometimes they would get strange errors and it all really hinged on which file was opened last (and thus set the current directory). The project system at one point even tried changing the current directory before each build, but that didn’t quite work because the current directory is not per-thread, so other threads running during the build would sporadically ‘break’ the build by changing the current directory! Many people often resorted to specifying a fully-qualified path name. Too bad this totally breaks source code control systems and exacerbates the security issue. It got even worse if you tried to build localized satellite assemblies that were also signed. Since the project system couldn’t easily read the key information (yes this could be viewed as a product bug or implementation detail), it relied on the same tool to read out the key information and then apply it to the satellite assembly. It’s the same pathing problems all over again only this time in spades.
The ‘solution’ was to make the project system manage the paths (something that it’s designed to do) and then pass the key file or key name in such a way that it is no longer embedded in the final PE. This solves the security problem and the usability problem. I’m personally miffed by our poor excuse for a project system. I’m hoping that it will get significantly better when it’s no longer a v1 product. They do have some ideas that potentially could help with project sharing, we’ll just have to see how it pans out.