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.
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.
We have a Windows Desktop only product suite that consists of several .exe applications and (obviously) quite a bunch of shared libraries between these apps. There's about 20 exe apps and maybe also about 20 shared libraries that are each used by several of these apps (some libs are very specific, some are just your good(?) old FooUtils.dll) Most code is C++, some C#.
Currently, all these reside in a single Visual Studio 2005 solution and are all built and released together. That works quite fine and each developer always can edit / see / debug any code he needs to. About 15 devs (mixed C++ / C#) on that product suite.
Now the problem
Due to migration pressure (language features, new 3rd party components) it becomes increasingly urgent to migrate some of the apps (read .exeprojects) to newer visual studio versions. Some to VS 2010 maybe (3rd party dependencies) some to VS2015. And some we just have not the resources to migrate them from VS2005 yet (third party constraints, as well as time/budget constraints).
This means that several of the shared C++ libraries will have to exist for several visual studio versions. (As opposed to the exe projects - these would just be built/maintained for one chosen VS version.)
Now the question
Given a set of (internal) shared libraries that need to be created for multiple different Visual-C++-Versions and that should be easily editable and maintainable for all devs, how are we to keep the Utils.vcproj(2005) the Utils.vcxproj(2010) and the Utils.vcxproj(2015) in sync?
Mostly to avoid manually having to maintain all files contained in the projects, but also regarding project settings / .[vs]props settings for these projects.
Ideas we had so far:
Just accept annoying triple maintenance of 3 project files in 3 different solutions (ugh.)
Use one of the vc.. project files as the master project and automatically (how??!) generate the other vc..files from it.
Use tools like CMake, Premake, ... ?? to generate these shared-shared library projects. (That would mean introducing a foreign configuration tool for our devs)
If you want to avoid manually updating your project files in separate versions of Visual Studio, you'll have to have a master configuration for the project of one sort or another. The two options you listed are basically your options:
Use one project version as the 'master'. In this case, the master must be the oldest version (VS2005 in your case?). Visual Studio has a project upgrade feature, to convert older projects to newer versions. When you load up an older project in a newer version, it prompts you to upgrade. This process can be automated with some simple scripting. Using devenv.exe <project/solution file> /upgrade you can upgrade a project from the command line.
Use CMake/Premake/etc. These add a little bit of overhead, but making supporting new platforms and configurations a lot less painless. If adding new dev tools is cumbersome to your process, and you're only supporting Visual Studio, the first option might be more suitable.
Visual Studio (at least VisualStudio 2010) stores the target platform settings in the *.suo file which obviously shall not be version controlled.
In my case this is no problem for the central build because that uses a command line option on msbuild that force the target platform to be x86 as required.
However, if a colleague checks out my project he will always end up building for AnyCPU and testing that. Because he has no *.suo file VisualStudio will use the default settings.
Bad or not, the colleague is obliged to test for x86.
Is there an easy way to safely persist the target platform for a Solution? An environment variable forcing the default is not exactly what we need but would be good enough and easy enough.
Visual Studio ... stores the target platform settings in the *.suo file
It doesn't, it stores it in the project file. A relevant snippet from one I created:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>x86</PlatformTarget>
// etc...
</PropertyGroup>
It is configured with Project + Properties, Build tab, Platform target combo box. Repeat for the Release configuration. Only the setting on the EXE project matters, that's the one that determines the bitness for the process. DLLs have no choice and ought to use AnyCPU.
In all likelihood you are being tripped up by a rather drastic design mistake in VS2010. Another item is the solution platform name, prominently displayed in the Build + Configuration Manager dialog for example. This was always AnyCPU for managed projects, VS2010 screwed this up royally by renaming the default to "x86". And creating a big old mess of it when you import projects from earlier versions, yielding a "Mixed platforms" configuration. And yes, the last selection is saved in the .suo file.
This is irrelevant to managed projects, it only matters to C++ projects. Where the setting selects a different set of build tools. The 64-bit compiler and linker are different programs. A non-existing issue for managed projects, bitness is determined at runtime by the jitter selection and you use the exact same C# compiler regardless of the desired platform target.
The best way to eliminate these kind of mistakes is by aggressively deleting platforms and only keeping one. Use Build + Configuration Manager, select the "Edit" entry in the upper-right combo box and click Remove for extraneous platforms until you only have AnyCPU left. Updating your VS version is also recommended, this mistake was corrected again in VS2012.
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.
I'm running Visual Studio 2008 with the stuff-of-nightmares awful MS test framework. Trouble is that it's sending my CPU to 100% (well 25% on a quad-core).
My question is why can't Visual Studio run on more than one core? Surely M$ must have a sufficient handle on threading to get this to work.
I have VS2008 running on all 4 CPUs. Just set this environment variable / project flag.
/MP
(It can be set in C/C++ Settings, Advanced. In project settings)
Edit: The MP flag can also accept a number, e.g. /MP2 which means it will only run on 2 cores. Leaving it as just /MP means it will run on the maximum amount of cores.
Edit2: The MP flag is probably for the compiler only.
You can ask VS to compile multiple projects in parallel as well as compiling parallelly (!?) within a project.
Tools > Options > Projects and Solutions > maximum number of parallel projects build.
This will build C++ and C# in parallel as well!
In case anyone comes across this old question, VS2012 introduced parallel builds as a standard feature. Quote from the article:
Visual Studio 2010 included an option for "maximum number of parallel
project builds." Although there was no indication of any restriction,
this IDE option only worked for C++ projects. Fortunately, this
restriction no longer applies to Visual Studio 11. Rather, there's now
full support for parallel builds in other languages as well. To view
this, run a copy of Process Explorer at the same time a solution with
numerous projects is building. You'll see that multiple MSBuild
instances are created -- as many as specified in the "maximum number
of parallel project builds."
Now that Visual Studio 2010 has been released for a bit, consider upgrading to make use of the parallelTestCount attribute in MSTest's .testsettings file, as described at How to: Run Unit Tests Faster Using a Computer with Multiple CPUs or Cores.
There are a few limitations, such as:
Only simple unit tests are supported (i.e. excludes coded UI tests and ASP.NET-hosted tests)
Tests must be thread-safe (all tests are run in the same process)
You can't collect code coverage (among other data & diagnostics) at the same time
Example, using 0 to mean auto-detect (the default is 1):
<?xml version="1.0" encoding="UTF-8"?>
<TestSettings
name="Release"
id="{GUID}"
xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>
These are default test settings for a local test run.
</Description>
<Execution parallelTestCount="0">
(...)
</Execution>
</TestSettings>
A few blogs have noted that you might have to close and re-open your project for Visual Studio to notice you added/changed that attribute. Also, if you edit the test settings file using the GUI, you'll probably have to re-add the parallelTestCount attribute.
We also added multiple core support for doing multi-threaded builds on the command line for those of you with a lot of projects and long build times. Enabling multiple core support requires only a few new properties, and MSBuild manages all of the work to schedule projects efficiently and effectively. The MSBuild team has tested this ability to scale by building some projects on a 64-CPU machine.
that is from somasegar blog
So they sort of started doing it, well at least for the build.
The /MP flag is only for builds, we at least it is according to this msdn
Now I would love to be wrong about it, but im pretty sure its just for builds. Which of course is still very useful.
I'm sure it's very hard. Huge existing GUI-heavy non-threaded code base to multi-threaded. Sounds like a 10 to me.
But it seems to use multi-cores to me. The Intellesense seems threaded. The build system has multi-project building and for C++ multi-file building as well.
You problems with these tools sounds a bit deeper then how well they use you CPUs.
For Visual Studio 2010 Go to Tools > Options > Projects & Solutions > Build and Run.
You will then see an entry to enter a number for the 'maximum number of parallel project builds'; my PC has an i7-3770 CPU, a Quad Core with HyperThreading, so it is set to 8.
For information on different versions of Visual Studio go here and select your version: https://msdn.microsoft.com/en-us/library/cyhcc7zc(v=vs.100).aspx
e.g. for Visual Studio 2010 this property only affects C++ builds:
Specifies the maximum number of Visual C++ projects that can build at the same time. To optimize the build process, the maximum number of parallel project builds is automatically set to the number of CPUs of your computer. The maximum is 32.
But for Visual Studio it's for C++ and C#:
maximum number of parallel project builds
Specifies the maximum number of Visual C++ and Visual C# projects that can build at the same time. To optimize the build process, the maximum number of parallel project builds is automatically set to the number of CPUs of your computer. The maximum is 32.