none
Getting manifest error in dll project upgraded to VS2012 from VS2008 RRS feed

  • Question

  • I upgraded a C++ project/solution from Visual Studio 2008 to Visual Studio 2012 RC and am unable to build all of my projects that are compiled as dlls (the static libs work fine).  Those that are compiled as dlls compile fine but then run into a linker error:

    3>LINK : fatal error LNK1117: syntax error in option 'manifest:embed'

    I looked at the project properties and don't see anything abnormal in the manifest settings.  For example, one project under Manifest Tool > Command Line shows:

    /verbose /out:"Release\pcoip_client_win32.dll.embed.manifest" /nologo

    I also verified that the /MANIFEST flag is present under Linker > Command Line.  Any guesses as to what is going wrong or how I can get more information?

    Tuesday, July 24, 2012 6:18 PM

Answers

  • Ok I finally figured out what the issue is.  It turned out that my Visual Studio 2012 environment inherited the settings from Visual Studio 2008 and as a result was using the build executables (e.g. the linker) from VS2008!  As a result, VS2012 was trying to feed in commands to the VS2008 linker and the linker was getting confused and failing.  I installed VS2012 on a machine that didn't have VS2008 and it is working fine.
    • Marked as answer by Adam Gross Friday, July 27, 2012 10:01 PM
    Friday, July 27, 2012 10:01 PM

All replies

  • Personally, I've never been a fan of manifests and tend to turn them off. And guess what: I never have any manifest problems. Any reason you can't do the same?

    (I understand I'm not really answering your question)

    Tuesday, July 24, 2012 7:05 PM
  • This dll doesn't show any UI so a manifest is in fact not needed, but unfortunately changing Linker > Manifest File > Generate Manifest to "No" doesn't fix the issue.
    Tuesday, July 24, 2012 7:33 PM
  • Something is very wrong here. Are you sure that each translation unit has been freshly compiled? It sounds like at least one of them has been missed. Try "Rebuild All".
    Tuesday, July 24, 2012 8:17 PM
  • Yeah I cleaned the whole solution and manually deleted all intermediate output and build files, but it didn't fix it.  I then selected Rebuild Solution but it still didn't fix anything.
    Tuesday, July 24, 2012 8:19 PM
  • Bizarre. Sorry, I'm out of ideas.

    Frankly, I've personally had troubles using the migration wizard when jumping more than one version at a time. I've often found it faster to create a skeleton project in the new compiler (ensuring that it compiles cleanly) and then copying the files or copy/pasting code from the previous version. It takes a few minutes but I've found it faster than trying to clean up the migration bugs. Perhaps you can consider that.

    Tuesday, July 24, 2012 8:34 PM
  • Ok I finally figured out what the issue is.  It turned out that my Visual Studio 2012 environment inherited the settings from Visual Studio 2008 and as a result was using the build executables (e.g. the linker) from VS2008!  As a result, VS2012 was trying to feed in commands to the VS2008 linker and the linker was getting confused and failing.  I installed VS2012 on a machine that didn't have VS2008 and it is working fine.
    • Marked as answer by Adam Gross Friday, July 27, 2012 10:01 PM
    Friday, July 27, 2012 10:01 PM
  • I have experienced the same issue, so I tried to uninstall and reinstall which didn't help either.

    Setting "yes" to "no" under the "Manifest File" of the "linker" tab doesn't work at all.

    Finally, I found a solution: under the "property" of the project, clicking "Manifest Tool" tab, and then "input and output" tab, and then "embed Manifest", you must set the "Yes" to "No".

    If you want to still keep your visual studio 2008,this solution might help.

    • Proposed as answer by legend wolf1 Thursday, October 25, 2012 5:06 AM
    Thursday, October 25, 2012 5:05 AM
  • I encountered this same linker error when I started using a VS2010 C++/cli project in VS2012.

    After a successful compile I went and added "<PlatformToolset>v110</PlatformToolset>" to a shared .props file thinking that all my C++ projects would then have that property set. It was then I started getting this linker error.

    However, upon further inspection I noticed that my "General->Platform Toolset" still said v100 (ie, VS2010). Meaning my shared .props file either couldn't define that property or it was being included too late.

    Solution? I manually added the PlatformToolset element to each .vcxproj like so:

      <PropertyGroup Label="Configuration">
        <ConfigurationType>DynamicLibrary</ConfigurationType>
        <CharacterSet>Unicode</CharacterSet>
        <CLRSupport>true</CLRSupport>
        <PlatformToolset>v110</PlatformToolset>
      </PropertyGroup>

    After that fix, everything was gravy. I could once again build without issue. I didn't touch any manifest properties either. I didn't use the property pages editor in VS so that each build config didn't have a PlatformToolset element. You could easily resolve this by editing your project's properties in VS itself.

    It should probably be noted that I also have VS2008 installed along side 2010/12.

    Friday, April 19, 2013 10:04 PM
  • You can try to define <PlatformToolset>v110</PlatformToolset> before the following line in the .vcxproj file:

    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />

    Tuesday, June 11, 2013 10:08 AM