我需要在 Visual Studio 中删除并重命名选定的解决方案/项目配置。有没有一个工具可以帮助解决这个问题？
我发现内置工具非常无用。例如，当我从解决方案中删除配置时，它将拒绝删除相关的项目配置，以防其他地方需要它们。此外，重命名解决方案配置不会重命名其相关配置。
必须有更好的方法来做到这一点。有替代工具吗？
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 configurations 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?
发布评论
评论（6）
简短回答： 否。
长回答： 排序（例如，您将集成“helper “工具不完整，并编写自定义脚本/工作来创建/集成到您的配置管理流程中）。
编辑评论：好问题。许多人都遭受过这种痛苦（正如对您的问题的“赞成”所指出的那样），我们都喜欢一个好的答案。
同意——内置工具毫无帮助。维护具有不同配置和依赖集的许多项目和解决方案非常困难，特别是对于不同的目标类型/平台。它具有一些特性，例如对项目、文件集和项目类型使用多个 GUID，这些 GUID 存储在注册表中，并可从
*.sln和* 内访问。 vcproj。该工具将尝试使用这些唯一标识符“修复”自身，取消所做的更改并忽略其自身的一些值，以“修复”项目/解决方案之间的连接。这会导致您的注册表和配置文件中出现大量“问题”，如果您将文件签入版本控制系统，则会对文件进行不必要的更改，以及文件的许多部分将被“忽略”的情况，甚至尽管您（正确地）做出了这些更改。
有些数据如“项目名称”、“项目配置名称”和“项目平台名称”有时是多余的，有时不是。由于 GUID，这种类型的“外部/手动维护”使您的项目/解决方案“看起来”引用了正确的项目（按名称），但错误项目（如由 GUID 唯一标识，通过注册表中的引用解决）。
而且，在这些文件中可以通过多种方式指定相同的内容，从而导致混乱（特别是因为
*.sln/*. vcproj文件本体没有很好的文档记录，将来也不可能有很好的文档记录）。简而言之，Visual Studio 是一个相当不错的 IDE，但对于构建和项目管理/维护来说却很糟糕。它似乎缺乏强大的核心设计。我承认这是一个（非常）困难的问题——人们已经在“构建”上工作了几十年，而恕我直言，最先进的技术并不是很好。然而，Visual Studio 绝对是一个“委员会设计”，包括从演变到主要现场修订的缺陷。
因此，对您的问题的“最正确”答案是“否”：Visual Studio 的设计目的不是执行您想要的操作（例如，在 Visual Studio 中维护解决方案/项目配置）。不过，我确信 Microsoft 的回应会是：“我们为您提供了 .NET API，供您推出自己的答案并编写自己的工具”。然而，经过对此主题的大量研究，恕我直言，对于使用这些类型的 API 的这些类型的工具，不存在合适的解决方案（尽管您可以跳入其中，并付出很大的努力，编写自己的工具以使维护更容易。
） ;2010 年有所好转，但对于构建和项目配置管理来说仍然不是很好。新的 API 很有帮助，但它们很困难，而且恕我直言，设计得不好。最有可能的是，微软永远不会认真解决 IDE 的这个方面：它是一个 IDE，旨在加速开发迭代，而不是用于构建项目和解决方案维护。 （如果您深入研究 MSDN 论坛，可以找到有关此主题的更多详细信息。）
是的，是的：对于所有构建系统，问题是“记录数据”，这就是您想要的配置：这些文件，这些定义的宏，这些命令行参数，这个目标类型等。从中（与源代码一起签入），应该生成“实际”构建文件/脚本。
当然，我刚刚描述了 CMake （它从数据记录源文件生成“构建文件” ），以及许多其他工具。他们是您最好的选择。在这种情况下，CMake 可以很好地生成
*.sln和*.vcproj文件，但很多其他工具不会（这有点困难，因为这些文件的复杂性，以及它们大部分没有详细记录的细节）。另一个可以很好地生成
*.vcproj的工具是 qmake，（这是一个很好的构建配置管理器工具，即使您不使用 Qt 库）。另一个（类似的想法）是 Google 的“gyp”（“generate-your-projects”的缩写） ”，它应该生成*.sln/*.vcproj文件，但我不确定它是否已准备好迎接“黄金时间”。对于所有这些工具，工作-流程意味着：
*.sln/*.vcproj文件*.vcproj文件，或者命令行构建如果您不需要外部工具，而是希望有一些“插件”。 文件进行本机操作的类型，我不知道有什么可以帮助您（而且我已经看过）。
一种对您的
*.sln/*.vcproj想法：存在一些工具可以对这些文件进行本机操作（例如一些人编写和共享的“版本迁移”工具），并且有些人谈到了构建系统本机“驻扎”这些文件作为数据-record，但是这些文件有点混乱，没有文档记录，并且对于 Visual Studio 版本来说是一个移动目标，并且不能很好地解决具有本地项目覆盖的集中式构建设置的集中问题，因此这真的很难做到。 （我认为，除了 Visual Studio 之外，目前不存在这样的构建系统，它“驻扎”在 Microsoft 本机文件上。）Visual Studio 2010 使创建这样的插件“更容易”以前的 Visual Studio 版本，但我认为这样的插件还不存在（我也不认为这样的通用插件成功的可能性很高，因为您所要求的并不是 Visual Studio 的优先事项，它主要是一个 IDE，而不是配置管理器）。相反，您很可能必须深入研究 .NET API 来编写自己的 API（重要的工作和维护），或者尝试依靠 Visual Studio 项目属性 （但我认为这不会给你你想要的）。
最后，（题外话），我正在编写这样一个工具，它依靠启发式方法来自动生成和自动维护这些类型的项目依赖项，并且我目前正在编写
*.sln/*.vcproj文件。它还没有准备好“黄金时间”，但我对您的具体项目配置管理问题感兴趣，并且如果证明对您有用，我愿意分享该工具（这是个人爱好 C++ 开发，目前是 Windows ，但应该毫不费力地移植到 POSIX）。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.
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
*.slnand*.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/*.vcprojfile 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.)
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
*.slnand*.vcprojfiles, 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
*.vcprojis 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/*.vcprojfiles, but I'm not sure it's ready for "prime time".For all these tools, the work-flow implies:
*.sln/*.vcprojfiles.*.sln/*.vcprojfiles 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/*.vcprojfiles, 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/*.vcprojfiles. 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).我怀疑是否有第三方扩展能够完全满足您的要求。然而，Visual Studio 2010 有一组相当强大的 COM 自动化接口，允许您自定义有关 IDE 任何部分的信息，包括配置管理器、配置、解决方案、项目等。您可以使用几乎任何您想要的语言，包括 C#、Visual Basic 6.0 和 C++。您甚至可以用 VBScript 编写宏。
以下是 Visual Studio 2010 对象的图形概述模型。
特别请参阅：
配置接口
ConfigurationManager 接口
配置界面
Solution2 界面
SolutionConfiguration2 接口
SolutionBuild2 接口
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
Visual Studio 2015 还有以下两个扩展。在撰写本文时，这两个扩展都是最近更新的，看起来很有前途。
ProjectConfigurationManager
更好的配置管理器
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 和 .vcproj 文件实际上是 XML 文件。我经常发现自己在文本编辑器中手动编辑它们来执行各种任务，否则这些任务似乎无法通过 UI 完成。
UI 经常执行不完整的操作，例如，在重命名项目时，并非所有条目都会更新。我通常更喜欢自己手工完成。
.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.
我自己不必这样做，但当我使用新的自定义向导 RRS 源时，如何将“debug”和“release”重命名为“Debugstatic”等其他名称 。
但是，您可能还应该查看以下信息：
了解构建配置
因为它表明执行此类更改可能会导致自动创建或分配项目配置和解决方案配置。
如果您希望将其作为可以运行的加载项，恐怕您可能需要编写自己的加载项。
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.
以下Roger Willcocks 的链接，我偶然发现了Carlos Quintero 的 博客。看来这是一本有趣的读物。除此之外，它还提到了尝试清理项目配置时面临的困难。
浏览一下 Microsoft 的文档，EnvDTE80 自 Visual Studio 2005 以来几乎保持不变。
查看 EnvDTE100...
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...