R – How to sign an assembly that reference unsigned COM interop assemblies

To avoid this error you could either:

• Load the assembly dynamically, or
• Sign the third-party assembly.

You will find instructions on signing third-party assemblies in .NET-fu: Signing an Unsigned Assembly (Without Delay Signing).

Signing Third-Party Assemblies

The basic principle to sign a thirp-party is to

1. Disassemble the assembly using ildasm.exe and save the intermediate language (IL):

   ildasm /all /out=thirdPartyLib.il thirdPartyLib.dll 
   

2. Rebuild and sign the assembly:

   ilasm /dll /key=myKey.snk thirdPartyLib.il
   

Fixing Additional References

The above steps work fine unless your third-party assembly (A.dll) references another library (B.dll) which also has to be signed. You can disassemble, rebuild and sign both A.dll and B.dll using the commands above, but at runtime, loading of B.dll will fail because A.dll was originally built with a reference to the unsigned version of B.dll.

The fix to this issue is to patch the IL file generated in step 1 above. You will need to add the public key token of B.dll to the reference. You get this token by calling

sn -Tp B.dll 

which will give you the following output:

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.33440
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):
002400000480000094000000060200000024000052534131000400000100010093d86f6656eed3
b62780466e6ba30fd15d69a3918e4bbd75d3e9ca8baa5641955c86251ce1e5a83857c7f49288eb
4a0093b20aa9c7faae5184770108d9515905ddd82222514921fa81fff2ea565ae0e98cf66d3758
cb8b22c8efd729821518a76427b7ca1c979caa2d78404da3d44592badc194d05bfdd29b9b8120c
78effe92

Public key token is a8a7ed7203d87bc9

The last line contains the public key token. You then have to search the IL of A.dll for the reference to B.dll and add the token as follows:

.assembly extern /*23000003*/ MyAssemblyName
{
  .publickeytoken = (A8 A7 ED 72 03 D8 7B C9 )                         
  .ver 10:0:0:0
}

I think I found the answer to your problem in Microsoft's Primary Interop Assemblies primer. PIAs are handled differently in Visual Studio:

When a user attempts to add a reference to a type library that has a registered PIA, Visual Studio will silently use the registered PIA instead of reimporting the type library with Tlbimp. This ensures that the PIA is used whenever possible.

This means that when you add a reference to your own IA to the project, Visual Studio will check whether there is a PIA registered for this COM object. The Outlook PIAs are registered under the following key:

HKEY_CLASSES_ROOT\CLSID\{0006F023-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0
    Assembly="Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"

From what I understand unregistering the PIA using the regasm tool should remove the key and re-adding the reference to your own IA should give the expected result.

However, Microsoft does not recommend to use custom IAs if there is a PIA available. I don't understand the exact reason for this, but I assume this might be related to marshaling optimizations and having unique type definitions.