C++ CLI and Assembly signing

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??

Cheers,
Franz

Answer 1

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

Any help would be great.

Cheers,
Franz

Answer 2

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.

Thanks,
  Ayman Shoukry
  VC++ Team

Answer 3

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

Answer 4

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?

Cheers,
Franz

Answer 5

Can somebody from microsoft take a look at this problem?

Answer 6

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?

Cheers
Franz

Answer 7

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 (/KEYFILE does not work...

Answer 8

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.

Answer 9

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

Greetings,
Stefan

Answer 10

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....

---

redbyron

Answer 11

RedByron,

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

Answer 12

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.

Stefan

---

There are two ways to write error-free programs; only the third one works.