Many people have asked about this to me, with a hesitation in their minds to delay sign their assemblies, given the message text that sits in the "Signing" tab page in Visual Studio (2005 and 2008) Project settings view.
Hence I thought I will blog my replies on this anyway, just so that it could be useful to all others out there with the same worry in mind.
When you attempt to setup partial signing, you can get confused or worried by the message that you see in the bottom of "delay signing" checkbox in Visual Studio setting page.
This is the message that gets people worried (at least at the first look/instance) and gets them thinking if they should skip delay signing completely.
To be frank, that message you see there, is not worth so much of importance as-is. I know what MS is trying to say there, but they have not used the correct message text to convey what they intended to say :-)
All that MS would want to convey there is that if you did delay signing, then (specifically for VS 2005) the hosting process - i.e. the <App name>.vshost.exe will attempt to block any debugging activity once the delay signing switch set to ON is detected.
This was the case at the time of VS 2005. This has been addressed now.
Also, the message is trying to say one other thing - I.e. since you will be signing only with a part of the full key pair when delay signing our app, the crypto bytes that gets into the assembly manifest will end up being null/0 bytes - which is expected.
But when the app is run, the CLR (runtime verification process) will detect this fact and then fail to load the assembly, since the encrypted hash will be 0 bytes, it will be taken as a tampered assembly, and hence will fail the .NET security verification process, and will end up throwing a FileLoadException, and consequently won't run the assembly.
Hence the message that you see in the Signing tab in the page saying that if you delay sign it, you won't be able to debug or run the assemblies.
But it is not fully correct on the part of MS to say what it says there, with just those words in there, because it can lead you to be confused.
What actually will happen is, in the context of development builds / tests / debugging, we will (obviously) need to switch off the run-time verification process - i.e. via the sn- Vr / secpol toolset + through our local development build scripts / process, which we will do anyway, if we are building delay signed assemblies, and will be debugging it for development tests, et al.
But what Microsoft overlooked (and continues to do so) is the fact that those who delay sign the assemblies will know to switch off the verification process in their sandbox / development machines in order to be able to debug the apps, and they simply came up with that message text that you see in the Signing page in VS 2005/8 setting page :-)
Although this may sound a trivial issue, it will be good on the part of MS to fix this message text in Visual Studio. This has been around from the time of VS 2005, but it is annoying to see this not addressed even in the VS 2008 release.
MS should either change the text, so as to make the information clear, or the note should be completely removed altogether.
I would personally favour the later option, since the host (vshost.exe) does not anymore detect this setting and disable debugging facilities (as it used to do in the early VS 2005 times), and also considering the fact that developers / teams who will be delay signing their project do know what they should prepare in order to debug/run their delay signed assemblies.
Anyway, until MS addresses this, rest assured that there is no need to get confused or alerted by that little (partially) incorrect message :-)
You can delay sign your apps, and run them, debug them et al.
Just ensure that your development build process has the scripts setup to switch off the run-time verification process.
That said, it is not advisable to simply switch off the run-time verification on all assemblies, since that can bring in security risks to your development machine.
Instead switch off the verification process only based on your delay signed assemblies's public key part token, with which you can then run a command something like this:
sn -Vr *, <your delay signed assemblies's public token part of the full secure key pair>.