An excerpt from it that sums it up:
Most people know about the delay signing feature of the CLR. (For those who don't check out MSDN's Delay Signing an Assembly for more details). Basically, delay signing allows a developer to add the public key token to an assembly, without having access to the private key token. Since the public key token is part of an assembly's strong name, it allows assemblies under development to carry the same identity as they will have when they are actually signed, however it does not require every developer to have access to the private keys.
For instance, at Microsoft, in order to get an assembly signed, we have to submit it to a special signing group, which are the only people that have access to the full Microsoft key pair. Obviously we don't want to go through this process for every daily build of the framework, let alone for each developer's private builds (imagine the debugging process if you had to wait for a central key group to sign each and every build you created). Instead of going through all of this overhead, we simply delay sign our assemblies until we get ready to make a release to the public, at which point we go through the formal signing process.
A delay signed assembly contains only the public key token of the signing key, not an actual signature. (Since, the person producing the delay signed assembly most likely doesn't have access to the private key necessary to create a signature). Inside the PE file produced, a delay signed assembly has space reserved for a signature to be placed in the future, but that signature is actually just a block of zeros until the real signature is computed. Because this block is not likely to be the actual signature value of the assembly, these assemblies will all fail to verify upon loading. (since their signatures are incorrect).