You may have heard that sealing Management Packs (MPs) is a good practice. This is definitely the case when you have MPs that contain classes, class extensions etc. because you can reference to those classes from other MPs. Referencing is only allowed when the target class lives in a sealed MP. To seal a MP you need a strong name key file. And you must know some other things. Read on to learn more …

MPs exists in two forms: sealed and unsealed. Unsealed MPs (.xml) are open to modifications and the origin is unknown because it has no information about the creator. Sealed MPs (.mp) are closed, cannot be modified, have been signed by the creator and are therefore more trustworthy. And you can reference to classes that live in sealed MPs, this is very important. So you have to decide what MPs to seal and what to use in an unsealed form.

If you need to seal a MP there’s only one requirement of having a private/public key pair that will be used to sign the MP file in the sealing process. This key pair can be generated by using the strong name tool (sn.exe) that is delivered when you install Microsoft Visual Studio. You will find it in the Microsoft SDK folder. Let’s check the usage options.

Wow, that a lot of stuff! So we will focus on the important stuff. First let’s create a new key pair –> sn.exe –k filename.snk

A random key pair (public and private) is created and stored in a snk-file. This is the file you will need to seal MPs, e.g. by using the Service Manager Authoring Tool. The output will be a sealed MP that can now be imported into Service Manager.

It makes sense if you use the same key pair to seal all corporate MPs. Using multiple key pairs can be very confusing when you are referencing to other MPs because you have to use different public key tokens. So to make things easier, generate a key pair, create a backup and use this and only this key pair for sealing all your MPs.

Now, if you create other MPs that reference to your sealed MP, a reference will be created in the MP reference section that looks something like this.

The reference contains an Alias, an ID, the Version and the public key token of the sealed MP.

• Alias: An Alias that will be used in the MP to do the referencing
• ID: The ID of the sealed MP
• Version: The min. Version that is needed of the referenced MP
• Public Key Token

Alias, ID and Version are very clear. But what about the Public Key Token? What is this used for? This is used to verify the signature of the referenced MP. The public key token is a shortened form of the public key. Actually the public key gets hashed and a part of this hash will be used as the public key token. When referencing to this MP, the signature will be checked against the entered value. When the signature can be verified, the referenced MP is valid and referencing is allowed. If the signature cannot be verified, the referenced MP cannot be used.

So how can we find out the Public Key Token of a referenced MP? The easiest way is to use the key pair that was used to seal the MP. From this key pair you can extract the Public Key and then calculate the Public Key Token. For this step you need sn.exe again –> sn.exe filename.snk filenamepublickey.snk

This generates another snk file that only holds the Public Key. This second file can now be used to calculate the Public Key Token, again by using sn.exe –> sn.exe –tp filenamepublickey.snk

In the output you will get the Public Key Token that can no be used in other MPs for referencing. Not too hard, huh?

Have fun sealing stuff
Marcel