locked
Visual Studio 2017 C++\CLI assembly not signed using platform v90 RRS feed

  • Question

  • Good morning,

    I'm trying to convert several project developed with Visual Studio 2008 to the newest 2017 IDE version. Some project are mixed mode assembly developed with C++\CLI.

    I have to preserve the application prerequisites (.NET Framework 2 and VC2008 runtime). If I select to compile using the Platform v90, the compilation succed but the resulting assembly is not signed.

    I have specified the .SNK file name, and the IDE show the resulting link tool command with the /KEYFILE argument.

    I don't have any error executing the build, but the assembly doesn't have any public key token.

    The problem occurs also if I try to create a new empty project.

    I've tryed also to add the /KEYFILE argument in the link optional parameter, but it won't works.

    I've also noticed that I cannot build an assembly for the .NET Framework 2.0 using 2017 toolset. If I try to do that, the built assembly will have two mscorlib and system assembly reference, one for the .NET Framework 2.0 and one for .NET Framework 4.0. Those built assembly cannot be used in other .NET Framework 2.0 application.

    Any idea?

    Best regards
    Taroni Mauro

    Tuesday, November 24, 2020 9:21 AM

All replies

  • For the first problem, you may want to add a post-build step to sign it with signtool.exe that comes with the SDK.

    For the second problem, I suspect there could be a mix-up in PATH variable. Check your system PATH settings and see if there is any SDK path being added there. You may also want to use "where" command to verify the program you used to build your application belongs to the folders you expected.

    Btw, just want to let you know that C++ support has been moved to the new Microsoft Q & A website.


    Wednesday, November 25, 2020 1:51 AM
    Answerer
  • Hi cheong00,

    thanks for the support.

    For the first problem I've resolved declaring the AssemblyKeyFileAttribute in the AssemblyInfo.cpp. But this is a workaround and I'm quite worried that everything seems correct in the command line but it doesn't work as expected, and maybe some other problem could arise in the future.

    For the second problem I've checked the PATH variabile but I can't found anything related to an SDK path. It also seems that the correct build command is invoked. I will investigate because I think that something is not working correctly in my build machine since I have similar problem on generating satellite assemblies for VB .NET and C# projects, because they we're generated for the wrong .NET Framework (4.0 instead of 2.0).

    Thanks for the advice regarding the C++ support: I've previously searched where to post but I haven't found the correct answer.
    Thank you

    Best regards
    Taroni Mauro

    Wednesday, November 25, 2020 10:51 AM
  • Hi cheong00,
    just for your information I've resolved the first problem regarding the assembly signing.
    The solution is described in the following forum (https://stackoverflow.com/questions/2656412/is-there-an-easy-way-to-sign-a-c-cli-assembly-in-vs-2010) and is due tue to a typo in the file Microsoft.Cpp.Win32.targets installed in C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32 by Visual Studio 2010 SP1.
    I'm still investigating on the second problem.
    Thank you
    Best regards
    Taroni Mauro

    Thursday, November 26, 2020 1:37 PM
  • > It also seems that the correct build command is invoked. I will investigate because I think that something is not working correctly in my build machine since I have similar problem on generating satellite assemblies for VB .NET and C# projects, because they we're generated for the wrong .NET Framework (4.0 instead of 2.0).

    I think it's more important to check the "cl" command being used.

    Btw, see if this thread can help you make it work.

    Friday, November 27, 2020 2:21 AM
    Answerer
  • Hi cheong00,
    thank you for the advice. I will try as you've suggested.
    Best regards
    Taroni Mauro

    Friday, November 27, 2020 7:45 AM
  • Hello cheong00,
    I wasn't able to perform what is suggested in the link you've posted. But I've noticed in the build log, that each cl.exe compiled file has been invoked with "/d1clr:nostdlib" argument. In the lc.exe command reference, a "/clr:nostdlib" argument is described (and maybe for the right purpose) and I cannot find anywhere a "/d1clr:nostdlib" argument.
    Do you think it could be a type in some cpp target file?
    Thank you
    Best regards
    Taroni Mauro

    Friday, November 27, 2020 3:09 PM
  • This switch is mentioned here and seems to be an undocumented switch.

    Note that I'm not quite familiar with C++, and you're recommended to continue ask question at Microsoft Q&A forum, where there ought to be more people using C++ for living can help you.

    Saturday, November 28, 2020 2:46 PM
    Answerer