Don’t Sign C++/CLI Assemblies with Attributes

We've already talked about using the /keyfile or /keycontainer switches to sign C# and VB assemblies instead of using the AssemblyKeyFile attribute.  When dealing with C++/CLI assemblies, using these switches becomes even more important.

The reasoning is that if the attributes are used, the assembly will be signed and then the linker will embed a manifest into it.  Obviously embedding the manifest will cause the signature to break, which will lead to C++/CLI assemblies being signed with the attributes to fail to load with a FileLoadException, saying that strong name validation of the assembly failed.

The correct way to sign a C++/CLI assembly is to use the /keyfile or /keycontainer switches to the linker.  Doing this causes the linker to embed the manifest before it signs the assembly, which keeps the signature intact.

Within Visual Studio, you can find these options on the Advanced settings of the Linker on the project properties:

VS signing dialog for C++/CLI projects

Comments (4)

  1. MichaelM says:

    Any reason why the new encrypted strong keys aren’t currently supported in VS2005?

  2. Joe says:

    Are you going to update the tools in order to reflect this behavior? Like, have the compiler issue a warning if it encounters the attribute and provide the workaround info?

  3. Michael — I’m not sure what feature you’re talking about. snk files cannot be encrypted in Whidbey.

    Joe — I can’t say for certain what the C++ team’s plans are, but that may be a possibility.


  4. Sam says:

    *sigh* this does not work for me – I mean, the code compiles well, and everything, but the strong name is not recognised belonging to the code group I created for it.

    My exe does not get the rights it needs to run.

    With, using assemblyinfo.cpp, it worked. With vs2005 (final release), it does not work anymore, neither with assemblyinfo.cpp, nor with this compiler switch.

    I tried not to embed the manifest. Didn’t help. The exe is just not being recognised as belonging to the code group 🙁

    I am running out of ideas here – how do I debug this?

Skip to main content