My IDE is Visual Studio 2010. I have a solution (.sln) containing more than 100 Projects (.vcproj). The language is C++. The solution has two configurations: "Release" and "Debug". The solution has two Platforms "Win32" and "x64". I need to create a third configuration, let's call it "Release_and_PDB". "Release_and_PDB" should be equal to "Release" except in that it should generate the PDB files. In the future "Release_and_PDB" should be always equal to "Release" except in that it should generate the PDB files. I think I can do it in three steps:
Create a new Configuration.
Manually change every project property adding the path and name for the PDB (in Linker, Debugging, Generate Program Database file).
Ensure that a property change in the Release will also reflect the same change to the Release_and_PDB configuration
My questions:
a. Does Visual Studio have any facilities to get the step 2 done without the need of manually changing the properties of any (and every) project?
b. Does Visual Studio have any facilities for the inheritance of project properties to get step 3 done without the need to also manually change the property in Release_and_PDB?
You go to configurations manager in the toolbar -> new -> copy settings from.
I think that's what you're looking for.
Related
I am building a "Solution" consisting of many small "Projects" within VS-2015.
To ensure consistency, I would like to set Project preferences such as additional include directories, additional libraries and platforms from one location or copy from one project to the next.
Could you please point me to a document that describes this?
Thanks in advance.
Since all projects are based on MsBuild, you can create a single targets file which sets the properties you want to sync across your projects. You can then import this targets file in every one of your project files.
To add a targets file you'll need to edit the csproj file directly (Unload project, edit project file in VS or through a 3rd party editor).
There are also some options like Directory.build.props and Directory.build.targets files, in Visual Studio 2017 these are automatically imported during your build and that gives you the advantage of not having to edit the project files. This may require MsBuild 15, which ships with Visual Studio 2017.
Some Visual Studio UI will be able to show the current value of certain properties, but editing them in the UI will pull these values back into to project files. This is an unfortunate behaviour of Visual Studio.
For all options to import targets files see:
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017
In Visual Studio 2010 through 2013, by default (eg. When I create a new Console Application) new solutions output their compiled executable into Solution name/Project name/bin/Debug/. I want them to be output into Solution name/Debug/, and likewise for all other build configurations like "Release".
I can do this by manually going into properties of each project, going to the Build tab, changing Output path from bin\Debug to ..\Debug. I must repeat this for every project and every build configuration.
After dozens of solutions, I'm a bit sick of doing this tedious task by hand every time. Is there a way to change the default output path?
A solution that works for Visual Studio 2013 is sufficient.
This property is defined in each Visual Studio Project Template
So, for example, the C# Console Application template is located in
\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ConsoleApplication\consoleapplication.csproj
The csproj is an XML file that you can edit at your will. The build output directory is define like this (for each configuration):
...
<OutputPath>bin\Debug\</OutputPath>
...
<OutputPath>bin\Release\</OutputPath>
...
If you change this file, it will change all your future new C# Console Application projects. You could also write a utility program that list all csproj in \Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ProjectTemplates and update them accordingly.
This is not necessary.
One of the projects in your solution is marked as the Startup project, shown in bold in the Solution Explorer window. An EXE project, like your console mode app. You used Project + Add Reference to add references to other projects in the solution so you can use the class libraries that those projects generate in your console mode app.
Those references will have the Copy Local property set to True.
When you build your project, MSBuild will automatically copy the assemblies from their respective bin\Debug directory into the bin\Debug directory of your console mode app, thanks to that Copy Local setting. And it is smart enough to also look at the dependencies of those class libraries and copy them as well.
So after the build is complete, the bin\Debug directory won't just have your console mode project's EXE file but also all the DLLs it needs to execute properly.
There are a few ways that this can go wrong and MSBuild cannot figure out that such a dependency actually exists. Pretty uncommon, you'd for example have to use Reflection in your code to load assemblies (Assembly.Load() and friends). The workaround for that is to explicitly copy the dependency in a post-build event. You didn't leave enough bread-crumbs in your question to judge whether that's the real problem.
What you ask for is certainly possible, the IDE just doesn't make it easy because it wasn't designed to assume this was necessary at all. You'd have to replace the Build + Output Path setting to, say, ..\Debug instead. You can create your own project template with that setting already preset. Create a new class library project, change the setting and use File + Export Template to create the template. You'll have it available the next time you create a project.
But, really, find out first why the default Copy Local machinery isn't working for you.
Rather than changing a global, protected file, you can create your own .targets file that changes the <OutputPath> however you want and import that into your projects. This could also set other defaults you might want to change and don't want to do for every project. All you'd have to do then in your project files is add something like toward the top (after the root element, of course):
<Import Project="$(SolutionDir)\Common.targets"/>
In VS 2010, or VS 2012, you can pick a "Solution Configuration", that has been custom defined, that can define local variables used with the #if #elif #endif syntax to change your code dynamically through that drop down. Also in that configuration, you can choose whether it's built or deployed, platform you're targeting, and the local configuration you want to use per project.
When you choose a configuration, then close Visual Studio, and re-open Visual Studio, it remembers what configuration you chose, what I can't seem to figure out, is where it saves/stores that configuration information, and I need to automate it.
Does anyone know of either:
A way to use the command line compiler to automate solution level builds using solution configurations
Where Visual Studio stores the currently selected configuration information
Or, ideally, both?
Visual Studio actually stores a solution's build configuration selections in the solution file itself. Even though the "*.suo" file is not checked into version control, the solution's build configuration selections will propagate to other machines that are sync'ed to the same version control system.
If you open a "*.sln" file, you will see a section called "GlobalSection(ProjectConfigurationPlatforms)". If a project is not checked for build or deploy, you will see something like this:
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Deploy.0 = Debug|Any CPU
The ".0" strings indicate that the the build and deploy are unchecked.
A way to use the command line compiler to automate solution level builds using solution configurations
msbuild.exe /p:Configuration="Solution Config" /p:Platform="Solution Platform"
For example, you can do:
msbuild.exe /p:Configuration="Release" YourSolution.sln
To build the "Release" configuration.
Where Visual Studio stores the currently selected configuration information
This is stored in the user's .suo file, next to the .sln (solution) file.
Is it possible to add visual studio macros to a solution, so they would be checked in by svn ?
If not, how do you deploy your utilities/scripts with your developer team ?
Unless I'm mistaken, VS Macros are stored in a .vsmacros file as selected when you created the Macro project (I think the default location is C:\Users\yourname\Documents\Visual Studio 2010\Projects\VSMacros80), so just copy that file to your project's directory and add it to the project with no build action and you should be all set.
But that's just if you want to use those macros only with that project, most macros are useful in many projects and if so I'd recommend keeping them where they are rather than in the folder of just one project, and then just add the .vsmacros file manually to subversion to some suitable location (suggestion would be a Tools folder) and check in and out manually when needed.
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.