Introduction
When developing web-parts for Microsoft SharePoint, a developer must confront the .NET runtimes Code Access Security and Strongly Named Assembly features.
There are several gotchas involved, one of which – mixing up public key tokens and blobs – is described here.
Details
Briefly, when an .NET assembly is compiled with a private key file, a public key and digital signature are embedded in the assembly – this means that if anyone who doesn’t have access to the original private key changes the assembly, then it will be noticed and rejected by the .NET Common Language Runtime (CLR).
The Public Key Blob is approx 128 bytes long – a bit too verbose for manipulating in configuration files – so there is also a Public Key Token, which is a much more manageable 8 bytes and is used more often.
The SN.exe utility has an argument (-Tp) to return the public key Token and Blob of an assembly. (Note the upper case T, this is very important and is described in more detail in this article)
So what does this have to do with me?
A SharePoint developer will likely have to use both the Blob and Token when developing web parts – and the Public Key Blobs and Tokens are easy to mix up (I have seen at least one book that mixes them up and several SharePoint bloggers have also made the same mistake)
To add your Web Part to the Safe Controls list you need the Public Key Token.
To generate a custom code access security policy you need the Blob.
If you are using the wppackager tool to create an install file then you need both – but don’t mix them up! The Token goes in manifest.xml and the Blob goes in wppackager.xml file.
Further Information
- Microsoft Windows SharePoint Services and Code Access Security
- Packaging and Deploying Web Parts for Microsoft Windows SharePoint Services
Tags: SharePoint
