We have a C++/CLI project currently in .NET 3.5 compiled using v90 (VS2008) compiler. Everything works fine. But when I change the project to .NET 4.0 with v10 compiler (VS2010), those linker error pops out:
error LNK2022: metadata operation failed (8013118D) : Inconsistent
layout information in duplicated types (tagTOUCHINPUT):
(0x02000743). ...\MainWindow.obj
error LNK2022: metadata
operation failed (8013118D) : Inconsistent layout information in
duplicated types (tagTOUCHINPUT): (0x0200072d). ...\stdafx.obj
The tagTOUCHINPUT structure seems to be part of MFC, which the project is heavily using.
I tried using ildasm -tokens, but it just crashes with empty error window.
I have no other ideas how to debug this project. Mainly because we inherited it and it is pretty old one. It is also pretty big, which means isolating the problem might be extremely hard.
Edit: After some work, I'm pretty sure I removed all references to native libraries from the project, except those automatically added by VS. The problem still exists.
Our solution have some old MFC based C++ libraries that was switched to /clr compilation for some reasons.
I got similar error messages when ALL projects in my solution was switched to /clr compilation.
Errors disappears when the main project (.exe) was compiled without /clr flag.
Related
I have two C++ Visual Studio (16.5.0 Preview 2.0) projects: a library and an application that uses it. The library project produces four .lib files (for x86/x64 and release/debug), which the other statically links against. The application was until recently working fine in all configurations. Then recently I modified the library and rebuilt the .libs, and now when I build the application for x64 with "Use Link Time Code Generation" enabled, it crashes at runtime with an (apparently impossible) access violation. Note that the x86 build works with or without LTCG, and the x64 build works without it ("No Whole Program Optimization"). I've tried clean builds of both solutions and double-checked that I'm linking against the correct .lib.
This probably isn't a lot to go on, but does anyone have an inkling what the issue could be? Could VS's LTCG somehow cause the linker to use the old code?
After reinstalling Visual Studio 2010, I recompiled the code and encountered the following error:
Error 'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt'
A solution mentioned that the lib file is incompatible and I need to install Visual Studio 2010 SP1. I did that, and now it has been solved.
I am wondering how can I check whether a lib file is created by SP1 or not?
I tried dumpbin, but I cannot find the version in its result.
It was not an incompatibility with your LIB file that caused the problem here, so checking the version of the linker that created it would not be a solution anyway.
The issue is that cvtres.exe (used internally by the linker toolchain) depends on a particular DLL (msvcr100_clr0400.dll) shipped with VS 2010 RTM. When you update to a later version of the .NET Framework (e.g., by installing .NET 4.5 or installing a later version of VS), this DLL is replaced. That stops cvtres.exe from working.
The reason why installing VS 2010 SP1 fixes it is because it actually modifies the cvtres.exe application to break the dependency. And now that all pieces of the linker toolchain work, you can compile and link the code without error.
Of course, there are other problems you can have when you start mixing libraries created by different versions of the compiler and/or linker. They aren't guaranteed to create 100% compatible output, so mixing them is not supported (at least not between major versions, I'm uncertain about how this rule applies to service packs).
In general, it's best to just recompile all libraries whenever you update your build system. The only time you wouldn't do this is if you didn't have the source code, in which case, you need to be very careful about updating your build system, lest you introduce gratuitous incompatibilities.
As far as determining the version of the linker that prepared a particular binary, using dumpbin.exe (included with the SDK) is exactly the correct approach. For static libraries, run the following command from the Visual Studio SDK Command Prompt:
dumpbin /rawdata:1 MyLibrary.lib
You'll see the assembly manifest, which will include the full path to the compiler used to build the library as well as the version of the CRT that it depends upon.
For dynamic libraries (i.e., DLLs) and executables, run the following command:
dumpbin /headers MyApp.exe
Look under the "Optional Header Values" section (not actually optional) for the version of the linker, along with a timestamp of when it was generated.
Note that you're very unlikely to find this information in release builds of a library or binary.
When building an F# project through Visual Studio 2010 (either Build or Rebuild, or Clean -> Build) where I've checked "XML Documentation file" and specified a location in the Build tab of the properties page, I frequently but sporadically run into build failures:
FSC: error FS0193: Access to the path 'xxx.XML' is denied.
I've experience this with several F# projects / solutions. Most of the time I then just turn it off, but I recently noticed then documentation isn't built into the compiled assemblies (I apparently falsely assumed that the XML doc was only for possible external processing and that the doc comments would always get built in).
Any help appreciated.
I know we fixed this bug in VS2010 for F#. I seem to recall that C# and VB had the bug as well (dunno if they fixed it, I can investigate). Do you have a C# or VB project referencing the F# project? (Are you building the solution, or a specific project?)
I'm trying to move my VS 2008 solution to VS 2010. Everything works perfectly (compile and link) if I keep the target framework at 4.0.
When I change the framework 2.0 and change the platform framework v100 (to get past compile errors) only to run into metadata linking errors, like this one:
error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000f7). C:\Development\Main\Filemaster\SoxService\MSVCMRTD.lib(managdeh.obj)
I've read that I'm supposed to use ILDAsm but it doesn't like my obj file and since the link didn't complete I don't have an exe to load.
Can anyone please provide some advice on how to find the sorts of errors?
I hate nothing worse than fighting the tool!
I was able to get around this problem by going into the project XML file itself and changing the TargetFramework to be 4.0 After that everything compiled and linked fine.
Hans he is referring to C++ Native Multi-Targeting which can be found at this location Platform Framework can be changed under project Properties > General and is advised by the article - however this does not work due to apparent bugs in VC++
I have a somewhat odd problem that I don't seem to be able to get to the bottom of. We have a mostly unmanaged C++ application that's been around for a while and thus has been built using lots of different versions of Visual Studio, with it being updated to the current version of Visual Studio on a regular basis.
I've now run into the following issue:
In VS2010 I've added two new projects to the existing solution. Both new projects are DLLs, one built in plain unmanaged C++, the built using a mix of C++ and C++/CLI and is thus built with CLR support (/clr). The second C++/CLI DLL should be used by several other components of the system
Using Properties -> Common Properties -> Framework and References, I add the two new DLLs as a dependency to a third DLL. The third DLL is doesn't know anything about .NET and is implemented in pure native, unmanaged C++. The new DLLs show up correctly in the dependency settings and the new references work in the sense that the build order of the solution is affected (correct), but for some reason, only the import library for the plain native C++ DLL is added to the linker command line for DLL that references both libraries. The second, mixed library generates an import library, but VS2010 doesn't add the import library to the linker command line which predictably results in several unresolved external symbols.
The one setting that appears to trigger this behaviour is building the DLL with Common Language runtime support as all the other settings of the libraries are identical.
I currently have a workaround for this issue - I simply add the import library as a manual dependency - but I was wondering if someone else has encountered this problem and if there is a way to get make this feature work as expected without the workaround?