Copy External Configurations to Local Projects in Visual Studio?

Question

What is the easiest way to create a build configuration in approximately 50-100 projects (same solution) IF Visual Studio has already detected the build configuration from another project?

Our team uses a set of common projects (namespace is simply "Common") within several solutions. The Common namespace has it's own master solution with its own set of build configurations. Common's solution contains five build configurations ("Debug-QA", "Debug-Dev", etc.).

Whenever these projects are used within a NEW solution (ie "MyNewSolution"), Visual Studio shows the build configurations from Common's master solution. Unfortunately, these configurations have not yet been created in MyNewSolution or any of MyNewSolution's projects. This creates a problem for ADDING the build configurations to the other projects, or including the projects in these build configurations, since there is no way to CREATE a build configuration if the name already exists (which Visual Studio thinks it does, thanks to the Common projects being included).

My goal is to add the same configurations (ie "Debug-QA", "Debug-Dev", etc.) into MyNewSolution, and its projects, so that all of the projects and solutions match. The only way I can see to do this is to manually create the build configuration on each new project... which is torture since MyNewSolution has approximately 50-100 projects.

FYI: I'm using Visual Studio 2012

Answer 1

This is more of a hack than a proper solution, but you could always:

1. Create aa copy of the configuration you want for the entire solution with a GUID as its name.
2. Remove the copy from the projects which already have the original configuration (undo changes).
3. Rename the GUID to the original configuration's name using the "Find/Replace in Files" tool.

Even if it isn't a very viable option, it is a pretty good quick fix.

EDIT:

How to manually remove configurations from solutions:

With the solution file opened in a text editor, you will see a block called Global which contains sections. The SolutionConfigurationPlatforms section contains the configuration's definitions. There is also an other section called ProjectConfigurationPlatforms where the configurations are assigned. Simply remove the references to the configuration from both groups and that should do it. If you have more complex solutions, there might be other references to remove. This is just a base case.

How to manually remove configurations from projects: Again, with the project file opened in a text editor, you will see many references to the configuration you want to remove. C# projects have a PropertyGroup with the configuration as a condition. You can simply remove the group entirely. There might be other references to the configuration around the file so make sure to clean everything properly.

Make sure that you have a backup of your files if something goes wrong.

Answer 2

If there is very little project-level customization of the target configurations, this would probably be simplest to manage via an externalized configuration imported into your individual projects via the MSBuild Import element .

In order to allow project-specific overrides, this Import should be placed near the top of the project files. eg:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="..\..\CommonConfig.targets" Condition="Exists('..\..\CommonConfig.targets')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    ...

This would, unfortunately, require you to edit all the project files once to add the Import . However, once this is done, you would be able to add a configuration to the imported .targets file and have it automatically propagate to all the projects.

Answer 3

I can't tell you what will work best for you, but I can say from experience that it becomes very easy to create new solution spaces with 50+ projects from old solution spaces when you don't let Visual Studio write the project files. Instead, you can take off-the-shelf third-party software that will read some configuration files you give it and in a few seconds will spit out a solution and all the projects you need, all configured the way you need them to be.

The same software would also generate the standalone "Common" solution when you just want to compile the common projects.

The right software will give you the flexibility and power that makefiles provide when you're setting up your projects, but you still get to do your work in Visual Studio.

I've used CMake extensively in that role, but for C++ rather than C#. I'm very happy with CMake; I have used it in environments with 50+ projects whose source code is scattered so far and wide that I use scripts to find it all, with some third-party libraries that are brought in as precompiled DLLs or LIBs. Also, from experience I know there's nothing stopping someone from concurrently maintaining their own hand-crafted set of VS project files for the same source code if they really want to. But of course you may want to do your own shopping around for the best software for your environment.

It is a significant investment of time to convert several dozen projects from hand-crafted project files to a more makefile-like system, but in an environment that requires reconfiguring or recombining the projects many times, I felt the investment paid back rather quickly.