What to consider when strong name signing a managed application?

Question

I want to strong name a managed application which references many managed assemblies and ActiveX and COM components (written in C++) via interop. And because a strongly named assembly cannot reference weakly named assemblies, could you please tell me what problems that I should be prepared for, what you have run into, especially when dealing with those ActiveX and COM interops?

The solution for this application is big. It's composed of 50+ projects of managed C#, Vb.net, native C++, and managed C++/CLI. Therefore, the more information, real life stories you give, the better I can prepare and save myself from headache.

Thanks.

Answer 1

I don't have real experience with this kind of visual studio solution yet. But I hope the information here and here can give you some ideas for your interop components.

Answer 2

There's really nothing problematic except reliably storing the .snk file.

Remember that every third party assembly that will use your assemblies will have the key from your assmeblies mentioned inside the dependencies and each time it will load your assembly it will check whether the loaded assembly is still signed with that key. This is done to prevent misplacing your assembly by some malicious code.

This means that unless you reliably store the .snk file used to signed the earlies version of your assembly you will be unable to ship new versions without enforcing the users to re-add the references. So store the .snk file and use the very same file for each version of any given assembly. Whether you use different .snk files for different assemblies or one for all doesn't really matter, so one .snk per company is enough.

See this question and this perfect answer for details on the above.

Answer 3

I have not experienced any issues related to strong names so far (also using COM interop assemblies). If you get a 3rd-party assembly which has no strong name, you can post-sign it yourself, allowing you to make all assemblies strong named.

Of course, making the interop assembly strong named doesn't protect the underlying COM DLLs to be modified or replaced, so that the "protection" from the strong name doesn't really extend itself onto COM components, even if the interop assembly is strongly named.