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
Related
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.
Using the CMake GUI, for the same CMakeList, I am able to generate VS solution files on Windows and XCode solution files on Mac. However I am unable to generate VS solution on Mac, as I don't use any VS options under Specify the generator for this project.
I have VS 2017 Community for Mac installed on the Macbook. Is there anything I am missing?
Visual Studio for Mac is very different from Visual Studio.
The former is based on Xamarin Studio, a product of Xamarin Inc., which was acquired by Microsoft in early 2016. Microsoft then basically rebranded Xamarin Studio as Visual Studio for Mac. Note that Xamarin Studio was mainly an IDE for developing mobile apps. Visual Studio for Mac currently has no support for C++.
Because of this, CMake currently does not support Visual Studio for Mac. The Visual Studio generators that ship with CMake only work with the Windows versions of Visual Studio.
And before someone asks: They also don't work with Visual Studio Code, which is yet another product that has little in common with Visual Studio except the name. Unlike Visual Studio for Mac however, Visual Studio Code has extensive support for C++ development with CMake through plugins and might be a viable alternative if you're looking for a Visual Studio-like development experience for C++ on Mac.
In that case, you open the workspace directly with VS Code and let its CMake plugins handle the configuration of CMake. You will not use the Visual Studio generators of CMake for VS Code, as VS Code is unable to work with the generated solution files.
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 want to build Boost 1_54_0 under Windows 7 using Visual Studio 2013. I opened a VS 2013 command prompt, cd'd into the boost_1_54_0 directory, and said bootstrap. I saw a message "Building Boost.Build engine", and then no indication of progress for hours. I couldn't find any way to abort the process, so I rebooted. Then I opened bootstrap.log, and the last thing in there is this:
C:\Code\boost_1_54_0_full\boost_1_54_0\tools\build\v2\engine>.\bootstrap\jam0 -f build.jam --toolset=vc10 "--toolset-root=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools....\VC\ " clean
That "Visual Studio 10.0" means it's actually trying to compile using the Visual Studio 2010 tools rather than 2013, right?
What am I doing wrong?
EDIT: for the record, I had 2 problems. One was the problem with Boost that was fixed by using the version from svn. The other was that VS 2013 provides 3 command prompt shortcuts:
Developer Command Prompt for VS2013
VS2013 x64 Cross Tools Command Prompt
VS2013 x86 Native Tools Command Prompt
Since I was trying to build 32-bit libraries, something with "x64" in the name seemed like the least logical choice to try, but it turned out to be the only one that worked.
First of all, Boost 1.54 and even 1.55 is not compatible with VS 2013 because VS was released after these Boost releases. You can take a compatible version at the Boost SVN.
See also the discussion here: How do I build boost with new Visual Studio 2013 preview?
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Compiling a MFC app from Visual Studio 2010 to 2012 RC results in LNK2038
I am moving an XPCOM Firefox add-on project from Visual Studio 2010 to Visual Studio 2012. When I open up the project, Visual Studio asks if I want the project to use the latest C++ compiler. If I say no then I get this compile error:
Error 1 error MSB8020: The builds tools for Visual Studio 2010
(Platform Toolset = 'v100') cannot be found. To build using the v100
build tools, either click the Project menu or right-click the
solution, and then select "Update VC++ Projects...". Install Visual
Studio 2010 to build using the Visual Studio 2010 build
tools. C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets 42 5 FF
(Visual Studio 2010)
If I say yes then I get five of these compile errors for xpcomglue_s_nomozalloc.lib in the xulrunner-sdk\lib directory:
error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't
match value '1700'
I cannot install Visual Studio 2010. I suppose I could compile Gecko myself, using Visual Studio 2012, although that seems like a lot of work and I'm not sure it will work. So please let me know the best way to compile my Firefox add-on in Visual Studio 2012.
When you are compiling binary XPCOM components you must use the same compiler as used to compile Firefox itself - otherwise the binary compatibility is just not given. Currently this means using Visual C++ 10, be it via the free Visual Studio Express 2010 or by some other means.
If the purpose of the XPCOM component is just to run some native code then you might consider compiling a regular DLL instead and calling it via js-ctypes, then you can use any compiler you like - no binary compatibility constrains (it is also generally recommendable since you no longer need to recompile for each Firefox release).