Is there an alternative / plugin for Visual Studio's configuration manager?_问答_开发者

I have the need to remove and rename a selection of solution/project configurations in Visual Studio. Is there a tool which will help with this?

I'm finding the built-in tool very unhelpful. For example, when I delete a configuration from a solution it will refuse to delete the related project configurati开发者_JAVA百科ons just in case they are needed elsewhere. Also renaming a solution configuration will not rename its related configurations.

There must be a better way of doing this. Are there alternative tools out there?

I have the need to remove and rename a selection of solution/project configurations in Visual Studio. Is there a tool which will help with this?

Short answer: No.

Long answer: Sort-of (e.g., you're going to integrate "helper" tools which are incomplete, and write custom scripting/work to create/integrate into your configuration management process).

Editorial comment: Great question. Many people have suffered this (as noted by the "upvotes" to your question), and we all would love a good answer.

I'm finding the built-in tool very unhelpful. For example, when I delete a configuration from a solution it will refuse to delete the related project configurations just in case they are needed elsewhere. Also renaming a solution configuration will not rename its related configurations.

Agreed -- the built-in tool is quite unhelpful. It is very difficult to maintain many projects-and-solutions with different configurations and sets of dependencies, especially for different target types/platforms. It has idiosyncrasies like its use of multiple GUIDs for projects, sets-of-files, and project types, which are stored in the registry, and accessed from within the *.sln and *.vcproj.

The tool will attempt to "heal" itself with these unique identifiers, un-doing your changes, and ignoring some of its own values, to "repair" connections among projects/solutions. This results in a lot of "cruft" in your registry and in your configuration files, unnecessary changes to the files if you're checking them into your version control system, and scenarios where many parts of the file will be "ignored", even though you (correctly) made those changes.

Some data like "project name" and "project configuration name" and "project platform name" are sometimes redundant, and sometimes not. Because of the GUIDs, this type of "external/manual maintenance" makes it very easy for your project/solution to "appear" to reference the correct project (by name), but the wrong project (as uniquely identified by GUID, which was resolved through a reference in the registry).

And, there is more-than-one-way to specify the same thing within those files, leading to confusion (especially since the *.sln/*.vcproj file ontology is not well documented, nor likely to be well documented in the future).

In short, Visual Studio is a pretty good IDE, but terrible for build and project management / maintenance. It seems to lack a strong central design. I concede that it is a (very) hard problem -- people have worked on "build" for decades, and IMHO state-of-the-art isn't very good. However, Visual Studio is most definitely a "design-by-committee", including cruft from evolution through major fielded revisions.

Thus, the "most correct" answer to your question is "no": Visual Studio is not designed to do what you want (e.g., maintenance of solution/project configurations in Visual Studio). However, I'm sure Microsoft's response would be, "We gave you a .NET API for you to roll your own answer and write your own tools". However, after great research on this topic, IMHO no suitable solution exists for these types of tools using those types of APIs (although you can jump in, and with great effort, write your own tools to make that maintenance easier.)

Visual Studio 2010 gets better, but it's still not great for build and project configuration management. New APIs are helpful, but they are difficult, and IMHO not well designed. Most likely, Microsoft will never seriously address that aspect of the IDE: It is an IDE, intended for accelerated development iteration, and not intended for build-project-and-solution maintenance. (Much detail can be found on this topic if you dig deep into the MSDN forums.)

There must be a better way of doing this. Are there alternative tools out there?

Yes, and yes: For all build systems, the issue is the "data-of-record", which is what you want for a configuration: These files, these defined macros, these command line arguments, this target type, etc. From that (which is checked in with your source code), the "actual" build files/scripts should be generated.

Of course, I just described CMake (which generates "build files" from a data-of-record source file), and a host of other tools. They are your best bet. In this case, CMake does a good job of generating *.sln and *.vcproj files, but not a lot of other tools will (it is somewhat hard due to the complexity within those files, and their largely not-well-documented details).

Another tool that does a pretty good job generating *.vcproj is qmake, (which is a good build configuration manager tool, even if you don't use the Qt libraries). Another (similar idea) is Google's "gyp" (short for "generate-your-projects", which should generate *.sln/*.vcproj files, but I'm not sure it's ready for "prime time".

For all these tools, the work-flow implies:

Update the data-of-record files;
(Re-)generate the *.sln/*.vcproj files.
Use the generated *.sln/*.vcproj files in your Visual Studio IDE, or command-line build.

If you don't want an external tool, but would rather have a "plug-in" of some kind that natively operates upon your *.sln/*.vcproj files, I'm unaware of anything to help you (and I've looked).

It's not a new thought: Some tools exist to operate natively on these files (like "version migration" tools some people have written-and-shared), and some people have talked about a build system natively "camped-on" these files as the data-of-record, but these files are kind of a mess, and undocumented, and a moving-target with regards to Visual Studio versions, and don't address very well the centralized question of centralized build settings with a local-project-override, so that's really hard to do. (No such build system exists at present which is "camped-on" the Microsoft native files, other than the Visual Studio, I don't think.)

Visual Studio 2010 makes creation of such a plug-in "easier" than previous Visual Studio releases, but I don't think such a plug-in yet exists (nor do I think such a generalized plug-in has a high likelihood of success, because what you're asking for is not a priority for Visual Studio, which is principally an IDE, not a configuration manager). Rather, you'll most likely have to dig into the .NET API to write your own (non-trivial work and maintenance), or try to lean on Visual Studio Project Properties (but I don't think that will give you what you want).

Lastly, (off-topic), I'm writing such a tool that relies on heuristics to auto-generate and auto-maintain these types of project dependencies, and I'm currently writing-out *.sln/*.vcproj files. It's not ready for "prime-time", but I'd be interested in your specific project configuration management issues, and am willing to share the tool(s) if it proves useful to you (it's personal hobby development in C++, currently Windows, but should port to POSIX with little effort).

I doubt that there is a third-party extension that does exactly what you want to do. However, Visual Studio 2010 has a pretty robust set of COM automation interfaces that allows you to customize just about any part of the IDE, including the configuration manager, configurations, solutions, projects, etc. You can use just about any language you want, including C#, Visual Basic 6.0, and C++. You can even write a macro in VBScript.

Here is a graphical overview of the Visual Studio 2010 Object Model.

In particular see:

Configuration Interface

ConfigurationManager Interface

Configurations Interface

Solution2 Interface

SolutionConfiguration2 Interface

SolutionBuild2 Interface

There are also the following two extensions for Visual Studio 2015. Both are recently updated at time of writing and seem promising.

ProjectConfigurationManager
Better Configuration Manager

.sln and .vcproj files are actually XML files. I often find myself editing them by hand in a text editor to perform various tasks that would otherwise seem impossible to do from the UI.

The UI often performs incomplete operations, for example when renaming a project not all entries are updated. I usually prefer to do it myself by hand.

I haven't had to do this myself, but there are some examples of doing this in code in How to rename "debug" and "release" to another name like "Debugstatic" something when I using a new custom wizard RRS feed.

However, you should probably also review this information:

Understanding Build Configurations

As it indicates that carrying out such changes may cause project configurations and solution configurations to be automatically created or assigned.

If you want it as an add-in you can run, you will probably need to write your own I'm afraid.

Following Roger Willcocks' link, I stumbled upon Carlos Quintero's blog. It is an interesting read, it seems. Among other things, it mentions difficulties faced when trying to clean up project configurations.

Glancing over Microsoft's documentation, it appears that EnvDTE80 has pretty much stayed the same since Visual Studio 2005.

Taking a look at EnvDTE100...