A common mistake when configuring the compilation/linking/etc. settings in VC++ 2008 is to set them in Release but not Debug (or vice versa) rather than setting them for "All Configurations". Any suggestions on how to avoid this kind of mistake?
Some beginnings of ideas that I have:
Find a way to make VC++ go to the "All Configurations" settings by default when you open the property pages rather than the active (Release / Debug) settings.
Have a VB script that can be run (inside or outside VC++) to check the project settings and raise any inconsistencies detected.
vb or js script is perfectly ok for the task. Just dont forget to teach it that some settings should differ, such as preprocessor defines, or used runtime libraries.
We recently switched to Qt's build (qmake) tool which is capable of generating both makefiles (used in batch product build) as well as project (.vcproj) files when working on individual projects.
The nice thing about it is that we have enforced all settings one could ever wish for beforehand once for all available build targets (i.e. we have debug, release and non optimized release) and have forgotten about manipulating settings ever since.
You can generate .vsproj files with CMake or Scons or similar cross platform build system.
Related
I have VS solutions with hundreds of C++ projects built using Azure Devops, these projects have a big mess of different project settings as projects have been created at different times over 2 decades, converted from different VS versions, etc.
We want to standardise some settings for instance building everything using c++17 standard. That's a compiler setting cl.exe /std:c++17 but I cannot see any way we can override this via msbuild/YAML; I'd initially assumed I could set it as a project property msbuild -p:std=c++17 but this isn't possible (for reasons I don't fully understand).
In another couple of years we might want to force all our code to build against the c++20 standard. Equally, we might want to compare builds flip-flopping between two settings. So: is there a way we can apply compiler settings at build-time which override the project-specific settings?
There seem to be two approaches (other than editing all the project files individually):
Use switch p:ForceImportAfterCppTargets on the msbuild command-line. This allows a .props file to be specified which is evaluated and overrides project settings. More information here: MSBuild: Custom.After.Microsoft.Common.targets for native C++ projects in VS2010 and in the docs
Use directory-level file Directory.Build.target file, this will be auto-discovered by msbuild and similarly override project settings.
The one downside is that these methods both seem to only apply to msbuild, not within Visual Studio itself, which can lead to confusion when something will build in the IDE but not on the build agent or vice versa.
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I had a solution with one project set to AnyCPU. Then I added a Console application as a second project, who's default Platform seems to be x86. Now it's ( - the Console application) being built as an x86 and I can't change it.
The "Solution Platform" always shows "AnyCPU". But when I show the Console application's properties -> build. It shows x86 without any way to change it. So how do I change it?
Go to Build -> Configuration Manager
Select for the overall solution the Active Platform = AnyCPU
Go to the Console Application line and Set the Platform to AnyCPU
If there isn't the voice create a new configuration
Check that the Console Application is flagged for compile.
Also look at this discussion about console applications default to x86
This is an unfortunate flaw in the VS user interface design. The solution's Platform name is not relevant for managed projects, it only means something for native C++ projects. Where "AnyCPU" doesn't mean anything since native code cannot run on any cpu. This got a wee bit better in VS2010 with a new default Platform name of "x86". Merely a wee.
The only setting that really counts is the Platform target setting for the EXE project. Project + Properties, Compile tab for a C# project. The class library project settings are not relevant either since it is the EXE that nails down the bitness of the process.
Best thing to do is just ignore it. You can make that more permanent with Tools + Customize and just drag the combobox off the toolbar so you don't have to look at it again.
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.
What's the difference between different Build Configuration settings e.g. Any CPU, Mixed Platform, WIN32 etc in Visual Studio.
As other platforms are already explained (i.e. X86 for 32 bit, x64 is for 64bit only, and 'Any CPU' can run in Both) I'll concentrate on Mixed Platform and how this is different from Any CPU.
The Any CPU is at the project level setting, whereas in the real world solution we have a number of projects under one solution, and there's a chance that some of my project use Any CPU but other uses the x86 or x64 build platform.
So at solution level automatically Mixed Platform will be selected. This indicates that during Build/Rebuild solution each project builds based on its selected platform.
Here's a link that helps explain the build configuration setting found in Visual Studio and its build files:
http://web.archive.org/web/20151215192101/http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/
Basically the setting states what platform the assembly is able to run on. When AnyCPU is selected, the resultant DLL is marked as able to run anywhere; when x86 is selected, the resultant DLL is marked as only being able to run on 32-bit systems and will not run in 64-bit applications or processes (but will run in 64-bit Windows;) and so on and so forth.
This just sets flags on the compiled DLL - it does not change other aspects of compilation process at all.
The build configuration names don't mean very much - they proliferate if you have C++ and C# projects in the same solution (and even worse if you have mobile projects too), because the various types of projects use different configuration names, so you end up with lots of them.
We try to keep deleting all the configurations we're not using, but that's hard work sometimes as often when you add a new project, unwanted configurations will be added back to the solution.
My recommendations is to decide on what configurations you need (by looking at the actual settings within them), and then remove everything else.
From: this post.
https://social.msdn.microsoft.com/forums/vstudio/en-US/81c72e8b-6335-4bf4-b7c0-b5c322edcaee/mixed-platforms-vs-any-cpu
When all of the projects in a solution are of the same type (e.g.
C#/VB projects) the solution configurations will match up exactly with
the project configurations. Once you have projects in a solution that
have mismatched configurations/platforms, Visual Studio creates the
solution level configuration(s) "Mixed Platforms/Debug" and possibly
"Mixed Platforms/Release". These configurations are just mappings to
individual project level configurations.
For example, if you have a C# project and a C++ project, typically
"Mixed Platforms/Debug" will map to "Any CPU/Debug" for the C# project
and "Win32/Debug" for the C++ project.