I need to build my C++ projects in two environments:
Visual Studio 2015 (VS2015) installed on Windows 10 x64
Visual Studio 2002 (VS2002) installed on Windows XP
Now every time I need to trigger to build my projects twice on 2 PC and this way is not sufficient for me.
I do some research before and someone suggest to install multiple compiler in one PC, but the problem is that VS2002 is too old to be installed on Windows 10 x64.
I am looking for any method or software tool that I can trigger the build once then I can build my projects on both VS2015 and VS2002 (e.g. if I can install both VS2015 and VS2002 in one PC, I can write a simple batch file to build my project in both compiler).
EDIT:
This answer is outdated because of clarification that the software is installed on two physically different machines.
If you have both VS .NET 2002 and VS2015 installed then you already have two compilers installed and they will be installed in two different places. You then should just be able to write a batch file to call each version of cl.exe (making sure the paths are absolute) and compile/link/build each project.
Related
Scenario
A colleague set up a system a while back. They installed Visual Studio 15 Comminity Edition, merely to test the build process.
At some later point, another colleague was assigned to use that machine. Unbeknownst to them, there was Visual Studio 15 still installed on this machine, but since we have commercial licenses they installed Visual Studio 15 Professional in addition to the alrready installed Community Edition.
Behavior
It is of important note, that the Community Edition installation had the MFC toolset installed, while the Professional Edition installation had not.
Afterwards, the second colleague used our automated procedure to call CMake to first generate project files for Visual Studio, then used the standard command to execute the build pipeline:
cmake -G "Visual Studio 15 Win64" .
This resulted in compilation errors, because the Professional Edition did not have the MFC toolset available and thus the build pipeline failed. Yet within the IDE compilation was successful. After a short while was discovered, that opening "Visual Studio" via Windows start menu resulted in opening the Community Edition rather than the Professional Edition. Since the MFC toolset was then availale, IDE compilation was successful.
Question
Is the solution to this problem as obvious as it seems or does CMake have some way to determine which compiler to use?
Currently I have the following assumptions and would like to validate or refute them:
Each of the Visual Studio versions came with their own compiler for which the respective installers are able to enable/disable additional toolsets.
These two Visual Studio versions do not share the same comiler. (That they do not share toolsets does seem obvious)
CMake has no additional settings to declare which of the compilers of these distinct Visual Studio installations is to be used to execute the build pipeline.
The reason CMake utilized the Professional Edition compiler to execute the build pipeline is merely because the Professional version was installed second, likely overriding a path (registry entry?) CMake uses to find the compiler.
Is this assessment correct? Did something else happen here?
I'm building MFC Application with CLR which can run on windows 10 x64 & windows 7 x64 and execute without installing Visual Studio.
First, I've tried to find a solution for app without installing visual studio.
After some works on google, I found some clues to this issue.
Release build doesn't require installing Visual Studio.
I was building the project on windows 10 x64. So the release version can work on other windows 10 pcs without Visual Studio.
But it can't work on Windows 7.
So I've got stuck in search on this issue until now and I found something.
"Build applications for both Windows 7 and Windows 10 with Visual Studio 2015" is a thing I found here.
The answer is right thing I've tried.
On their comment, I saw one word - CMake.
I'm not sure that I can accomplish my solution with this - CMake.
Is there someone to told about this thing?
Or anyway to fix this issue?
Thank you.
CMake won't help you.
I think you'll need to install Visual C++ Redistributable for Visual Studio 2015 on any machine where Visual Studio was not installed, if the redistbutable package was not installed yet.
You also need to use .NET framwork which installed on both machines, I guess .NET 4 is good enough.
EDIT:
Try to run your exe from a console, and check if there is some print for missing dll or something.
Anyway, you can use dependency walker to check if you're missing some dlls, (download the x64 version) drag&drop your exe into it and check what prevent it from run.
Now, I found right solution about this m own question.
As a matter of fact, #SHR is helpful for this answer, but there's something to modify for right solution.
Installing .NET 4.0 is right and it's mandatory for working on Windows 10 & 7 x64.
But "Visual C++ Redistributable for Visual Studio 2015" should not be necessary.
Without these packages, the app can executes on windows 7 & 10 x64.
Of course, the app requires some dlls in C++ Redistributable packages. But not all.
So I put dlls the app requires at the same directory of .exe file.
That's all.
There's no other requirements.
I have recently acquired source code from a VS2005 project that uses the MFC library. Firstly I upgraded the project to VS2012 and I can now successfully build and run the software on Windows 8. Next, I wanted to deploy the software on a Windows XP machine.
I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and I have installed the 'Visual C++ Redistributable for Visual Studio 2012 Update 1' on the target machine. When I run the software, nothing appears to happen. Via some logging functions I can determine that a call to LoadFrame(IDR_MAINFRAME) causes an exception in kernel32.dll. I can't debug any further in to LoadFrame as remote debugging on Windows XP is not available in VS2012.
Any ideas what may be going wrong? Is the Visual C++ Redistributable package the correct version to be installing on the target machine? What should I be trying next?
UPDATE
My project is already set up to use the 7.1 SDK and has minimum required version set to 5.01 in linker options.
If I use InstallShield to generate an installer and include the MFC, CRT and ATL redistributables, the installer works and my program now runs on Windows XP. My understanding of the redistributables is that they simply copy the relevant dll's in to the system32 folder (or equivalent)? Is that correct?
However, if I simply copy the files over, run the vsredist_x86.exe or use Inno Setup to install the software & dll's, my program no longer works.
I believe you have read this blog. In summary, you need to use the 7.1 SDK, and you need to set minimum required version to 5.01 in linker options.
Using the working InstallShield project and the not-working Inno project I was able to determine that the real culprit here was an unregistered msxml4.dll. The error I was receiving gave no real clue to this outcome but I got there eventually...
regsvr32 msxml4.dll
I installed VS 2012 Professional and the XP update as well. I built my project with v110_xp as the platform toolset on VS 2012. My project's .msi package is installing fine on Win 7 but failing on Win XP SP3. The error reported on XP SP3 is -
"The procedure entry point FlushProcessWriteBuffers could not be
located in the dynamic link library Kernel32.dll".
While the same project built from VS 2005 is installing fine on XP SP3. I am not sure what is going on VS 2012. _WIN32_WINNT is set to 0x0501. Can some one please guide as how to resolve the problem ?
Any help is highly appreciated,
Mahesh.
Yes, the C Runtime has a dependency on FlushProcessWriteBuffers(). The updated version of msvcrt110.dll and libcmtl.lib, the ones you got along with the update, no longer directly link to the function, they use GetProcAddress() to find it and limp along if it is missng. So you should never get this error.
So very high odds that you deployed the wrong version of msvcrt110.dll, an old one instead of the updated one. You can find it back in c:\windows\system32, look at the properties. Mine is version 11.00.51106.1, dated 11/5/2012. A separate installer is available for it here.
The VS2012 runtime that you are installing uses functions that are not present available in XP. See this MS article: Targeting Windows XP with C++ in Visual Studio 2012 which explains more and provides some workarounds.
Update 1 for VS2012 resolve the problem.
But Update 1 isn’t just about new Windows platforms. It also enables you to target Windows XP with native C++ applications in Visual Studio 2012.
If you are building with update 1 and still encountering problems then I suspect that you are installing an out of date runtime. You need to deploy the runtime delivered with update 1.
You can solve this by including the VC11 merge modules from your development machine(program files\common files\merge modules) in your installer. It's easier than having to run the redist exe in your installer.
If you use WIX: merge module addition
I've tested on server 03, xp64 and xp32.
I want to use the June 2010 SDK rather than the Windows 8 SDK to compile my DirectX code in Visual Studio 2012 on Windows 8 Release Candidate.
The problem is that since the DirectX 8 SDKs are in the same folder as the Windows SDK, I don't know which include/library folders I can change.
As it stands, seemingly nothing I change in the directory settings or the linker settings solves the issue of something or another referring to the Windows 8 SDK, which causes a bunch of redefinition warnings among other things.
Has anyone been able to get this to work?
Not sure this is the easiest way, but I ended up installing VS2010 and compiling that way.
As a side note, the DirectX June 2010 SDK fails to install correctly (probably for Windows 8 reasons), but it leaves the \program files folder intact when it finishes -- so all the .libs and .hs are there to use.