3

I have a unmanaged C++ dll, which will be used by a managed C++/CLI wrapper .dll, which will eventually be used by a C# project.

C# project is strong-named, so is the wrapper .dll. I tried doing the same for the unmanaged dll, using /KEYFILE, but doesn't seem to work. And the wrapper is complaining:

.... is a strong-name signed assembly and embedding a manifest invalidates the signature

Do I need to strong-name the unmanaged C++ at all? If not, how do I resolve this issue?

M W
  • 1,269
  • 5
  • 21
  • 31
  • 2
    C++ does not have the concept of a "strong name". Assemblies, and their names (whether strong or not) are not part of C++ or basic .dll work. They're .NET constructs. – Nicol Bolas Jul 18 '12 at 23:13
  • Then how do I resolve the build warning in the wrapper class and the eventual error when trying to run the C# application? – M W Jul 18 '12 at 23:16
  • possible duplicate of [Strong name dll - how to troubleshoot?](http://stackoverflow.com/questions/11549339/strong-name-dll-how-to-troubleshoot) – Nicol Bolas Jul 19 '12 at 02:38

2 Answers2

4

Finally got it all working, i.e. my C# app calls C++/CLI wrapper dll, which calls a class in native C++ dll!

To solve the problem: 

mt.exe : general warning 810100b3: ... MyWrapper.dll is a strong-name signed assembly and embedding a manifest invalidates the signature. You will need to re-sign this file to make it a valid assembly.

IMPORTANT: It turns out the strong name in referenced class was not the issue.

It turns out there is something wrong with how VS sign the wrapper dll in this case. See link: http://blogs.msdn.com/b/vcblog/archive/2011/03/11/10140139.aspx

In short, to solve this, in your wrapper C++ class, add this as your Post Build command to re-sign: 

sn.exe -R $(SolutionDir)$(Configuration)\MyWrapper.dll MyKeyFile.snk
M W
  • 1,269
  • 5
  • 21
  • 31
  • If SN asks for a password prefix the "sn.exe" line above with `ECHO | ` to pipe in your password, per the SO post by me here: http://stackoverflow.com/questions/3138106/auto-entering-password-in-sn-exe/14657401#14657401 – Derreck Dean Feb 02 '13 at 01:13
3

It is not possible to strong-name a native DLL. Most of all because doing so is meaningless, only the CLR will ever validate a strong name and only does so on .NET assemblies.

Just in case: a strong name is not a substitute for a code-signing certificate. Biggest hint this is so because you don't have to hand over a big wad of money to anyone.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks Hans! That confirmed I was totally going to the wrong direction :( Can you give me another hint for what I am trying to do? I am thinking I should just do [DllImport ...] in my wrapper. Am I on the right track? – M W Jul 19 '12 at 02:58
  • Ok I think I get around the problem, by simply making the native code runs on CLR (using /clr). It is still unmanaged code (as I didn't use any managed feature), but it is running on .NET. That way I can strong name it. Otherwise I need to use P/Invoke, and the only material I found is here: http://www.codeproject.com/Articles/14180/Using-Unmanaged-C-Libraries-DLLs-in-NET-Applicatio which seems very involving. – M W Jul 19 '12 at 17:00
  • The signing is actually free. The only thing you have to pay for is a signing certificate which is trusted by Windows out of the box. But for corporate uses, you can use internal-only certificates. – MSalters Jul 19 '12 at 19:02