I have a cmake project (cmake 3.19.0-rc1) that I want to build using Visual Studio 2019 (Microsoft Visual Studio Community 2019 Version 16.7.6). There are no toolchain files in the project.
The solution and project files are created via
cmake -G "Visual Studio 16 2019" -A Win32
The solution is created successfully with the Win32 target platform. The first build works as expected.
However after that, Visual studio informs me that the project and solution file has changed outside of the IDE and that they need to be reloaded. After that the target platform is x64.
I can manually re-add the Win32 target platform, but with every compilation, visual studio resets the target platform to x64.
How can I stop this behavior and just stick with the Win32 platform?
Apparently it was a Visual Studio extension (Clang Power Tools) that decided it needs to edit the stamp files. This caused a recreation after the build process.
The problem was solved by deactivating and deinstalling the Clang Power Tools extension.
Related
I have tried to switch to Visual Studio 2019 since it is now officially released, but I am having problems building a C++/CX based project.
I have not retargeted the project, but it is still configured to use the v141 platform toolset, i.e. Visual Studio 2017 Build Tools.
As far as I can tell, I have specifically installed the required build tools in Visual Studio 2019, which should be evident here:
Still, according to the project properties, Visual Studio 2017 Build Tools are not installed:
And when I build the project I get the following error:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(378,5): error MSB8020: The build tools for Visual Studio 2017 (Platform Toolset = 'v141') cannot be found. To build using the v141 build tools, please install Visual Studio 2017 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution".
Am I still missing some components in my installation, or is this a bug in Visual Studio 2019?
EDIT I should point out that I still have Visual Studio 2017 installed on the same computer as well.
I had a similar issue, but this is what I was missing.
You will find these options on the Workloads tab of the VS installer on the right under Installation details (i.e. not under Individual components).
It turns out that the (Windows Runtime Component) project was not properly set up. In the .vcxproj file the ApplicationTypeRevision element was missing, which is also "evident" (if you know what you are looking for...) from looking at the project properties above, where only the General configuration properties node is visible, and the Target Platform value is empty.
Inserting the following line in the .vcxproj file immediately following e.g. the WindowsTargetPlatformMinVersion element should do the trick:
<ApplicationTypeRevision>10.0</ApplicationTypeRevision>
Most likely, it was also necessary to add the C++ Universal Windows Platform Tools. The v142 version was made available when trying to create a new C++ Universal Windows Platform project. As far as I could tell, this component was not otherwise visible in the Visual Studio Installer? Once the v142 component was installed, the corresponding v141 component was also available for installation.
I had this same problem for Visual Studio 2017, even though V141 was explicitly shown as installed. It turned out the problem was that VCTargetsPath was set in System Environment Variables to "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\V4.0\V140". Removing or unsetting this variable solved the issue.
I suspect this variable was set during an earlier install of Visual Studio 2015. Even after uninstalling all other Visual Studios the variable was never removed and the problem persisted.
I am using Visual Studio 2013, but I'm in need to develop an old project using the Visual C++ 6.0 compiler.
For this purpose, I have been using Daffodil with no problem on Windows 8.1 for a while.
(You can read more how to use the VC++ 6 compiler in newer Visual Studio versions in this StackOverflow question: Is it possible to use the VC++ 6 compiler in Visual Studio 2012?)
Now I got a new Windows 10 machine, where I reinstalled Visual Studio 6, 2010, 2013 and Daffodil.
Using v60 build tools (Visual C++ 6.0 compiler), project gets compiled fine.
However, when I try to debug, VS says that "debugging information does not match", and I am unable to set breakpoints etc., but:
PDB file is there, same folder and name of debug executable;
Application built in Debug mode, with debug information enabled;
Debugger works fine when using Visual Studio 2010 or 2013 build tools;
Debugger works fine if opening the project inside Visual C++ 6 IDE.
I tried reinstalling all Visual Studio versions as well as Daffodil, but didn't solve.
Any clue what could the problem be?
Finally I actually found a working solution!
for VS 2013:
Enable "Native Edit and Continue"
under Tools->Options->Debugging->Edit and Continue
for VS 2015:
Enable "Use Native Compatibility Mode"
under Tools->Options->Debugging->General
Is there anyway to install or have VC++ Debug Runtime Distributable without installing Visual Studio ?
Just to run a dll that has been compiled in debug mode using VS2013 on another machine that hasn't VS2013.
For testing purposes, you can include the Debug DLLs you need 'side-by-side' with your application. You can find them on a machine with VS 2013 installed:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\Debug_NonRedist
When you deploy your app, you must use Release mode distributions. For Win32 desktop apps, use these instructions. For Windows Store apps, you don't have to deploy the CRT as it's handled by the Windows Store.
OP was asking about 2013, but the title is general, so..
I just wanted to point out that in newer Visual Studio releases with the "select what you want" installer, for the debug runtime you need just "tools" or "build tools" (e.g. VC++ 2017 version 15.9 v14.16 latest v141 tools or MSVC v142 - VS 2019 C++ Build Tools, not to be confused with the toolset)
As for where you can find the libs, VS 2015 still has them basically in the same path outlined in Chuck's answer. From 2017, you should have something like:
<root>\Microsoft Visual Studio\2017\Community\VC\Redist\MSVC\14.16.27012\debug_nonredist
I wish to generate a x64 project for Visual Studio with cmake. Unfortunately, cmake always generates x86 projects. The generator name I use is "Visual Studio 12 Win64". cmake is run from x64 VS developer console, yet still projects are generated for x86 and CMAKE_SIZEOF_VOID_P is always 4, not 8. There are no errors during project generation. Could this be a bug in cmake?
For me determining the the size of a void pointer with cmake started to fail after I switched the MSBuild project output in Visual Studio 2010 from "Normal" to "Diagnostic". Everything worked fine again after switching back to "Normal".
I have a C++/CLI app that is built under Visual Studio 2010 but using .Net 3.5. As required, I hand edited my project file to add the TargetFrameworkVersion with a value of 3.5 and was able to build it without issue when I was in x86 (32-bit) mode. However, when I switched to build it in x64 (64-bit) mode, I got the following error:
error MSB8014: Execution path (C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\x86_amd64) could not be found.
I do have VS 2008 (9.0) installed, but there is no x86_amd64 directory under the bin folder. I tried fooling it by adding this folder (and the amd64 folder which would have failed thanks to the next line in the targets file), and then I got the error:
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
which I can't figure out because my project has no explicit links. I switched the C# assemblies that it interacts with to build in x64 (as opposed to any CPU) but to no avail.
FYI: Everything builds correctly in 32-bit mode. Everything also build correctly in 64 bit mode if I switch to .Net 4.0 (v100). I get the same errors building in both release and debug mode.
Any ideas would be appreciated.
If you are compiling with the "toolset" changed over from V100 to V90 on the project properties, and you have Visual Studio 2008 installed on the same development machine, just go to Control Panel, Programs and Features, select Visual Studio 2008, right-click, select Uninstall/Change, then select to add/remove f eatures, then when you are presented with a list of features, look for x64 compiler/files under Visual C++ which is not installed by default,but by clicking on the checkbox next to it, it will add the needed files.
In VS2010 it should link to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64
You probably got configuration wrong, or imported from a vs2008 project.
Go to Configuration -> General -> Platform Toolset. make sure it's v100 (vs2010)
If that doesn't help , look at Configuration -> VC++ Directories. That's where that path is set.
You can see that it looks in $(VCInstallDir) which in your computer is set to the VS2008 path.