I inherited an old program from a colleague that is no longer with the company. It's an CPLEX optimization we use. It was built in house in C++ using Visual Studio 2005 and CPLEX121. The server where it's located is being decommissioned and we're trying to migrate it to a new server. I'm trying to rebuild the new application in Visual Studio 2013 using CPLEX126 for the optimizations.
Error I get is:
Description:
error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1800' in (project name).obj
File:
ilocplex.lib(ilocplex.obj)
There are quite a few of these mismatches. I'm new to Visual Studio and C++, but I've managed to work through getting the CPLEX links updated, and now this error is happening.
From this forum post:
error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1700' in CppFile1.obj
I've been able to deduce there might be something I can do to the toolset or "recompile my libraries" this seemed to work for some people on the last post, but all I need more specific help on how exactly to do that.
No, it's the object files. What the compiler emits. They appear to be inside the .lib file. You'll need to recompile it. – David Heffernan Oct 24 '13 at 20:40
Hi David, iam new to c++ .Iam basically a c# programmmer. Can you please elaborate the comments – user1654136 Oct 24 '13 at 20:43
2
The compiler is telling you to recompile Projectname1.lib with VS2012. – David Heffernan Oct 24 '13 at 20:48
I have no idea what that means and I don't have enough reputation to comment.
Also,
for each project in your solution make sure that
Properties > Config. Properties > General > Platform Toolset
is one for all of them, v100 for visual studio 2010, v110 for visual studio 2012
you also may be working on v100 from visual studio 2012
the response is "That worked for me"
My Project's Platform Toolset is "Visual Studio 2013 (v120)". Do I need to add some other toolset? there's no other option in the dropdown.
There is also a block of code in the .cpp file:
// set up Visual Studio version
#define _VS2005_
# if _MSC_VER < 1400
# undef _VS2005_
# endif
I also don't know what this is doing to see if it is causing the error.
First - you will not be able to recompile the CPLEX library because you will not have the source code and there is no way you are going to get it unless you work in the R&D team inside IBM. So forget that line of reasoning. You are dependent on IBM providing a pre-built library that works with the version of the compiler that you are using.
When you say that you "managed to work through getting the CPLEX links updated, and now this error is happening", I am guessing that you managed to update the paths to the C++ include files that are used by the compiler, so your compilation errors have gone away. But you may not yet have updated the library paths to show the compiler the right sets of libraries to link with.
From the error you are posting, '_MSC_VER': value '1600' doesn't match value '1800', that says to me that you are trying to link with the CPLEX library built for VS2010, while your code was compiled using VS2013. See for example How to Detect if I'm Compiling Code With Visual Studio 2008?
If you are new to C++, it is plain crazy for anyone to expect you to walk into a large existing code base and try to port to new compiler and libs and get it to run straight away without doing a bit more research and background learning. Have you tried to build and run the C++ examples provided with CPLEX?
Have you read the instructions for setting up a C++ project with CPLEX? They are in a file c_cpp.html in the CPLEX folder.
Now, I don't know that CPLEX has libraries for VS2013. I haven't got 12.6 here, so I can't be sure. Have a look in your installed copy of CPLEX, probably something like:
C:\Program Files\IBM\ILOG\CPLEX_Studio126\cplex\lib
...and that should tell you what versions of VS are supported. I have x64_windows_vs2008, x64_windows_vs2010 and x64_windows_vs2012
If there isn't a copy of the library for VS2013, then I think you are going to have to go back to VS2012 or VS2010. There may be a way to configure VS2013 to make it work like VS2012 and trick it onto generating code that is compatible; but I am guessing that would not be a "supported configuration" from IBM's perspective.
The stuff about #define VS2005 is using the C++ pre-processor to define a symbol which can be used to turn on or off bits of your source code. Look for where in your source code that symbol is used. I am guessing that is entirely separate from your linking issue. You might choose to do something similar if you make changes in your code to make it work (or work better) with the newer version of the compiler and libraries.
Tim's answer is entirely correct, but here's the piece that he couldn't check...
There doesn't exist CPLEX libraries for VS2013, so you should not spend time looking for some... This can be seen in this report, which you can access for other platforms/versions from the CPLEX Optimization Studio Detailed System Requirements.
This means that you will have to use Visual Studio 2012 compiler. You can still use the Visual Studio 2013 environment: what you have to do is to install both versions and instruct Visual Studio 2013 to use the compiler from version 2012 by changing the Platform Toolset. But all the other libraries that your application uses must then have been compiled by the Visual Studio 2012 compiler. You can't mix and match...
Related
At the start I'd like to note that I've spent some time researching this issue and suggested solutions for similar questions like this one didn't help me.
Problem background
I need to migrate a Firebreath plugin project (which I haven't worked on previously) from PC_1 to PC_2.
As far as I'm aware the project was started on PC_1 on Visual Studio 2010 and later moved to Visual Studio 2013 Pro. There's one solution consisting of 19 projects. I have an instruction which says that in order to get the plugin installer I should first Build project_x and after that Build project_y_WiXInstall. Both steps work without any issues on this machine.
Then there's PC_2 which had Visual Studio 2015 Community installed before I started working on it. I've removed it, installed Visual Studio 2013 Pro (version 12.0.21005.1 REL - exactly the same as on PC_1), moved all of the needed files and I'm trying to get rid of all of the compilation errors. So far I figured out I had to install Cmake 2.8, Windows Driver Toolkit 7.1 and manually override an incorrect VCTargetsPath MSBuild variable
Problem description
Currently when I try to compile the project on the new machine I get these two errors (this is an image link since I can't embed images yet on this account). I'm not sure what's going on with the first error message since it looks incomplete and the file CUSTOMBUILD doesn't exist, but I'm not bothered by it too much since the previous compilation error I fixed also had a similar "artifact" as the first error and it disappeared after fixing the second one.
The covered part of the second error message is the project path. The error origin (Microsoft.Cpp.Platform.targets file, line 64) looks like this:
<!-- Error out if toolset does not exists in Visual Studio 2010 or 2012 -->
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_CurrentPlatformToolsetShortName);$(PlatformToolset)" Condition="'$(ToolsetTargetsFound)' != 'true'" />
What didn't help
The error description suggests using an Upgrade Solution... option, but there's no such thing when I right-click the solution
As an accepted answer for the question I've posted at the start of my post suggests, I've checked the Properties of all 19 of my projects (including the project ZERO_CHECK) but their Platform Toolset is already set to Visual Studio 2013 (v120).
I've also tried changing the Platform Toolset to inherit from parent or project defaults for all of the projects. This resulted in it switching to Visual Studio 2010 (v100) (not installed) and after that I've right-clicked on the projects and chose Upgrade VC++ compiler and libraries. After this the Platform Toolset was back to the Visual Studio 2013 (v120) but it didn't help with the compilation error.
As a NON-accepted answer for the question I've posted at the start of my post suggests, I've tried searching for all of the occurrences of 10.0 and V100 in all of my .vcxproj files to replace them but I haven't found any occurrences of them.
[EDIT]
I just got an idea to try building the project with MSBuild from the command line. There's a bit more info compared to errors inside Visual Studio, so maybe it will help with resolving the issue: https://pastebin.com/JhN3dXM3
So the thing you're missing here is that FireBreath projects are built using CMake -- the actual contents of the build directory should always be completely temporary and never stored in source control. To build the project on a new computer you need to run the prep command again from scratch.
If the previous maintainer changed the build files manually and/or migrated it to a newer version of visual studio without using cmake to do it then they did some very ugly things and all bets are off... good luck.
This is why all the firebreath documentation (I wrote most of it) strongly urges that the build directory be transient and you always do project file updates in cmake.
Hope that helps!
I must work on a Visual Studio C++ solution done many years ago by a corporation that doen't have C++ experts.
I have few experience with C++, a lot with Visual Studio, but zero experience on those two together (when I used to program in C++ it was always for Linux).
This solution has 9 projects and used to compile for Windows Embedded using Visual Studio 6.0 under Windows XP or Windows Vista.
I now must make it compile for x86 and ARM, using Visual Studio 2017 under Windows 7.
The only error I have on compiling is well-known:
Can't find assembly windows.winmd. Specify the path using/AIor set the environment variable LIBPATH.
If I follow the advice and add C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0 to the /AI parameter of the main project, I get 100+ compiler errors.
The previous error I had was: missing "platform.winmd", but after adding to /AI the path to that file the error disappeared. Solving the problem "windows.winmd" isn't trivial at all, because I have many of those files on my computer.
I just want to compile the project and I'm banging my head against this single error. Can someone help?
I would say with 99,999% probability, it is impossible to work with WinCE projects in VS2017. You really need to have old good VS 6.0 that is equipped with necessary toolchains and project types (indeed they're obsolete now).
Also, there is a non-zero chance you have to have lower OS version (something like WinXP or so) as some CE-time SDKs can be not compatible with Win10.
I am trying to builda c++ code which was developed VS 2010
I can compile it, but during link, I am getting this error:
Error 1 error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1700' in myfile.obj
I know that it is because they are build with different version of MSVC, but is there any way that I can configure MSVC to use libraries compiled with older version of MSVC?
Edit 1
At the end , I decided to install VS2012 express and compile code with it. It seems the Microsoft doesn't like you to port one project from one version of MSVC to another one easily.
You have three solutions to solve this problem :
Recompile the VS2010 library in 2012 (but you need the sources). Or if there is already an available 2012 library (but you already check it I guess).
Or you can do :
In Project Properties, select General and then change the "Platform Toolset" setting to "Visual Studio 2010 (v100)."
Or you can link your library as external.
MSVC static libraries are binary incompatible between major versions (at least those which use Microsoft's STL implementation):
C++ Standard Library implementation intentionally breaks binary
compatibility among versions of Visual Studio (2005, 2008, 2010,
2012). (source)
You can either:
recompile external library with same compiler
move your code to compiler same that external library use
link external library dynamically (.dll)
My project is compiling and running OK in debug and release modes in VS 2010.
Today I tried to compile it with VS 2012 and I got this error :
1> Generating Code...
1>pcrecppd.lib(pcrecpp.obj) : error LNK2038: mismatch detected for '_MSC_VER':
value '1600' doesn't match value '1700' in NamesEditorDlg.obj
I searched for "_MSC_VER" in the code but I could not find any match. Neither could I find "1600" or "1700".
So I am wondering how I can solve this problem.
Looks like you're using a .lib from vc2010 in vc2012 (at a guess it looks like a PCRE library). You'll need to recompile all your .libs or run-time link with the DLLs (ie LoadLibrary, GetProcAddress etc.).
In Project Properties, select General and then change the "Platform Toolset" setting to "Visual Studio 2010 (v100)." After I did that, my code compiled fine with the original libraries.
Looking it up at http://msdn.microsoft.com/en-us/library/b0084kay.aspx It seems that variable holds the compiler's version number. I would think the best way to fix it would be to create a new project in 2012 and add the source files to the new project.
NO, all that you need is is check properties of the project. There exist link to old project files. Need open project properties on page ".NET Framework and links" there del all links end add new for new 2012 project files.
Me and my partner are both sharing a c++ solution via subversion.
He is using Visual Studio 11 and I am using Visual Studio 2010.
After the first time he commited and i updated, i get the following error:
Error 31 error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
also, in header files i get the following error on #include <stdio.h>:
error: cannot open source file "stdio.h"
I am guessing this is a compatibility issue. How can we resolve this?
In Visual Studio 11 there is a property option that allows you to specify the platform toolset.
Platform Toolset v110 is used by default if you create a new project starting from Visual Studio 11, but if can change it to v100 that is the one used by Visual Studio 2010.
.sln and .vcxproj files saved in Visual Studio 11 are not backward-compatible with VS2010. Even if they were compatible, eventually you'd step across a code which is compilable in VS11 but not in VS10.
The best (and probably the only) way is to agree on using exactly the same development environment.
A bit late in the discussion, but since you're using source control, you can remove the project and solution files from the repository and just share source code. Obviously, if you add new modules and such to a project, you'll have to manually add them in the other solution, but at least you wouldn't have to worry about this incompatibility. If you wanted to get down to it, the application can be built from the command line using just the compiler and linker switches, which tend to be far more compatible between revisions. Finally, you could use another build tool (besides MSBuild), that remains compatible across studio versions.
If you decide to remove the solution and project files, one thing to consider is saving a copy of the original YourApp.sln as YourApp.sln.2010. Then you'll have something to seed future solutions from, but updates to projects and solutions will all need done from VS 2010 and the file then copied to their .2010 version and maintained manually.
If SVN has support for patches, or if you're willing to run quilt externally (or if you switch to mercurial, you can use the MQ extensions), you can create the patch files to convert from 2010 to 2011 and remove the upgrade patche(s) before synch.
Drake's solution didn't work for me as the properties for all projects in the solution were already correctly set to v100. However, the fix that did work was to clean the builds and remove all other files that weren't source files or project files. I think it was probably removing the files projname.vcxproj.user that fixed it, as perhaps the toolchain preference was somehow overriden in the user preferences.