C++ CLI and Assembly signing RRS feed

  • Question

  • Hi,

    we are using a pfx file for signing our c# assemblies. Now we have also some C++/CLI
    (managed c++) assemblies. When I try to sign the assembly with our pfx file with the
    /keyfile linker switch - I get the following error:

    Error    1    fatal error LNK1256: ALINK operation failed (80090007) : Ungültige Anbieterversion     TestDll 

    when I use a snk file instead - everthing is ok. With our C# projects we have no problem
    signing with a pfx file.

    Any ideas??


    Monday, December 12, 2005 1:15 PM


All replies

  • Has nobody the same error when using a c++/cli assembly and a pfx file for signing?

    Any help would be great.

    Tuesday, December 13, 2005 11:21 AM
  • I have sent an email to folks that might have more details and pointed them to the forum post.

    Meanwhile, take a look at http://msdn2.microsoft.com/en-us/library/h4fa028b.aspx where you can find more info.

      Ayman Shoukry
      VC++ Team
    Tuesday, December 13, 2005 4:52 PM
  • I believe you have the concept "Assembly signing" and "Authenticode signing" mixed up.

    Assembly signing is an managed code only concept where you provide a key file (*.snk) to strong-name signing a managed application.  The key signature is embedded in the metadata. It gives an application or component an unique identity. See http://msdn2.microsoft.com/en-us/library/h4fa028b.aspx for detail.

    Authenticode signing is for any executable (both managed and native).  You supply a digial certificate (*.pfx) file, and use the SignTool.exe ot put the certificate on the image.  See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/signtool.asp for detail.

    Curtis Man
    Visual C++ Team
    Tuesday, December 13, 2005 6:31 PM
  • Hmm,

    no I think I don't have mixed the two issues. In a c# project I can use a pfx file to generate
    a strong named assembly. Now I have a managed c++/cli dll and I want to sign (strong name)
    that assembly too. When I use a *.snk file for that c++/cli assembly then everything is ok - but
    when I use a pfx (like in the c# assembly) then I got that error.

    What do you think?

    Wednesday, February 1, 2006 2:59 PM
  • Can somebody from microsoft take a look at this problem?
    Thursday, February 2, 2006 7:03 AM
  • Just wanna bring this thread up again. We are using one pfx file for all our c# projects (and this is really a huge amount). Now it seems we can't use that pfx file for the managed projects - this is really annoying. It would be great if somebody can help us?

    Friday, February 10, 2006 7:07 AM
  • Has anyone found a fix for this? I'm using a managed C++ dll. The C# assemblies are signed ok, but using the same file to sign the C++ dll (/KEYFILESmile does not work...

    Wednesday, April 18, 2007 2:57 PM
  • Creating a new keypair solved the problem.

    sn -k KeyPair.snk

    I now use the same one for the C# assemblies, but a different one for each managed c++ assembly.
    Wednesday, April 18, 2007 3:14 PM
  • Hello,

    I have had exactly the same error when using a PFX file that works fine for C# assemblies, but not for C++/CLI assemblies. I found the following workaround working for me: In the C++/CLI project' settings specifiy the PFX file as Key File, and turn on "Delay Sign" two lines beneath in Advanced linker settings. The Linker error LNK1256 will be gone with that, but since your assembly is only delay signed yet, you need to run sn.exe on it afterwards to fully sign it:

    sn -R yourassembly.dll yourpfx.pfx


    Friday, March 27, 2009 12:25 PM
  • Hello,

    Although there is no activity on the thread i have overcome the problem and i will share the trick for those who are interested.

    Instead of delay signing the assembly, specify the PFX file as Key File and put in the Key Container field the container for the pfx, eg.VS_KEY_57E869135D0F5B5E

    in the Advanced linker settings.

    The above works like a charm for me....


    • Proposed as answer by st3v Thursday, December 22, 2011 8:56 PM
    Tuesday, October 5, 2010 11:05 AM
  • RedByron,

    Thanks for your answer! I came across this issue today and your post was a lot of help!

    Thursday, December 22, 2011 8:59 PM
  • Interresting approach. Thanks for sharing.

    I believe it has one problem, though: When working in a team of developers everyone has to tweak their copy of the project file because the container name (VS_KEY_57E869135D0F5B5E in your example) will change from machine to machine.


    There are two ways to write error-free programs; only the third one works.
    Wednesday, January 4, 2012 12:42 PM