At my company I've become the go to guy for installers and the like. Naturally one of my jobs is doing builds in visual studio for including in those installers. As we write security software we always sign our assemblies to prevent tampering.
For anyone that has had this job you know that signing assemblies is a fairly trivial task. You change the AssemblyInfo file to point to your private key pair, set delay sign to false and off you go. In a matter of minutes you have a set of fully signed assemblies to deploy to your hearts content.
The problem lies in when your solutions start to get large, say greater than 8 projects. That 8 AssemblyInfo files to update. Since you all work in perfect worlds where builds go out on schedule and everything works magically I'm sure this has never happened to you. Imagine you receive word from a customer your software, which is in production, has a defect. *GASP* sound the alarm, drop everything and jump! Your team mobilizes into seek and destroy mode to find the defect and fix it. But you need to get the fix to the customer in a easy to deploy fashion. So you whip up a patch installer throw in the requisite assemblies and off it goes.
As your customer is happily installing your fix you start to wonder, did I update all the assembly info files in my solution?? Maybe I missed one. Just as you go check your code your customer calls back stating the installation failed due to a signed assembly problem. AHHHHH! If only there was a way to update one AssemblyInfo file and have it affect all projects. Well there is!
To begin solving this problem we turn to some built in functionality in Visual Studio. In Visual Studio there is a concept of linking files. The idea is you have one common file, an AssemblyInfo file in this case, and you link all your projects to that one file. So you change the file in one place and it is affected in all projects. Slick eh? The one exception to this is web projects. I'm guessing because of how web projects are built and ran (from temporary ASP.NET) you can't link files to them. To access the menu in the Add Existing Item dialog, click on the small arrow to the right of the Open button.
Now having a common file is really handy, but what if you type the path to the private key pair wrong or forget to turn off delay sign. Well you're in luck, by using #IF/#ENDIF statements you can control assembly signing simply by changing the configuration. 
To make Visual Studio take advantage of this you will need to edit the project settings and define the symbols to switch on. The DEBUG symbol is already defined by default, so all you will need to do is define the RELEASE symbol. This is accomplished by opening the project properties, selecting Configuration Properties, selecting Build, and adding the word RELEASE to the list of semi-colon separated list for Conditional Compilation Constants.
When you put this all together you can control whether you delay sign or fully sign you assembly by changing one option in your development environment. By selecting Release from the configuration drop down the code in the AssemblyInfo file that controls signing is switched to use fully sign the assembly. |