How do you programmatically (re)sign a .NET assembly with a strong name?

Question

Aside from invoking the command line to add a strong name to an assembly, is there any APIs out there that let you resign an assembly once it has been stripped of its strong name?

Wagoner

I deleted a reply (command line); I'm not aware of any other ways of doing this except the command line (sn -R etc) – Hartman

Did you find a way to do this? – Bubo

An assembly isn't necessarily "Stripped" of its strong name so much as it is created without one, or the one that it has becomes invalid (due to tampering). – Confiscatory

Duplicate with correct answer here: #7782234 – Rubbing

Answer 1

It depends on what you mean by an assembly being "stripped of its strong name". If an assembly is not strongly named, nothing (not even sn.exe) can resign the assembly until it has been re-built with a strong name.

But to answer your question: all of the strong naming functionality is exposed through the CLR's unmanaged strong naming API. Specifically, you want StrongNameSignatureGenerationEx, which, as you'll notice, is functionally equivalent to the sn -R[a] command.

That being said, it is much simpler and easier to just invoke sn.exe itself. Accessing the unmanaged strong name APIs is not for the faint of heart, since (as of .NET 4) you are forced to go through the CLR's metahosting APIs first. For this reason, you're also pretty much stuck with having to do this entirely in unmanaged code. (I did find a managed wrapper from Microsoft on CodePlex, but I couldn't get StrongNameSignatureGenerationEx to work properly through it.)

If you have to, though, here's a rough outline of how to access the strong naming APIs from unmanaged code:

• Obtain an instance of ICLRMetaHost or ICLRMetaHostPolicy by calling CLRCreateInstance.
• With that instance, obtain an instance of the current runtime (i.e. an ICLRRuntimeInfo instance). There are numerous ways to do this; see MSDN for the gory details.
• Once you have an instance of ICLRRuntimeInfo, obtain an instance of ICLRStrongName by calling ICLRRuntime's GetInterface method, passing in CLSID_CLRStrongName and IID_ICLRStrongName for the class/interface identifiers.

Now that you have an instance of ICLRStrongName, you can finally call StrongNameSignatureGenerationEx using it:

// This is the ICLRStrongName instance you'll need. Assume GetStrongNameAPI
// corresponds to an implementation of the rough process I outlined above.
ICLRStrongName *snAPI = GetStrongNameAPI();

// You'll have to load the .snk file into memory yourself using the Win32
// file APIs, the details of which I've omitted for the sake of brevity.
BYTE *keyPairBlob = NULL;
DWORD keyPairBlobSize = 0;
LoadKeyPair(&keyPairBlob, &keyPairBlobSize);

// Once you've got the key pair blob, you can now (re-)sign the assembly
HRESULT hr = snAPI->StrongNameSignatureGenerationEx(
    L"path\\to\\your\\assembly.dll", 
    NULL,
    keyPairBlob,
    keyPairBlobSize,
    NULL,
    NULL,
    0
);

// Do whatever error handling needs to be done with the given HRESULT

(Optionally, if you want to sign with a key container instead of a .snk key pair, you can pass in the name of the key container as the second argument and leave the key pair blob/size arguments as NULL.)

Bottom Line: As you can see, unless you really have to go through the strong naming API, it is much easier to (re-)sign an assembly by just invoking sn.exe itself.

Polyandry

Answer 2

You could look into mscoree's strong name APIs, but I wouldn't recommend it.

Personalty

Why not? I'm looking to do this also, and don't want to spawn sn.exe (mainly because I want a more "elegant" mechanism) – Bubo

These APIs are deprecated starting with .NET 4. – Personalty

They're only deprecated because of the introduction of in-proc SxS in .NET 4; i.e. the global static functions are deprecated. The unmanaged strong naming API itself isn't deprecated—you just have to call it from the hosting interfaces instead (specifically, ICLRStrongName: msdn.microsoft.com/en-us/library/dd409349.aspx). – Polyandry

The .NET 4.0 version of those methods have been moved to the ICLRStrongName interface. msdn.microsoft.com/en-us/library/dd409349.aspx – Confiscatory