我有三种解决方案，其中方案A需要在编译之前使用方案B和C中的DLL构建版本。将它们合并到一个解决方案中是不可能的...
到目前为止，似乎Visual Studio不支持解决方案引用，如果我尝试使用msbuild这样的方式，它会聪明地知道你正在从另一个解决方案构建一个解决方案等等。总体目标是让多个解决方案看起来几乎像只有一个 - 就是方案A。
我相信这是一个常见的问题，但如何很好地将它们链接起来呢？
如何链接多个Visual Studio解决方案？
50
- simonjpascoe
3
为什么你不能将它们合并成一个解决方案？ - Brian R. Bondy
为什么你不使用msbuild呢？ - eglasius
5由于B和C不仅仅用于A，所以我们无法将其放入一个解决方案中。在开发中，它只是作为vs构建而构建的；如果msbuild更好，请说出原因！ - Simon P
9个回答
32
这个问题以不同的方式出现过，但是都是相关的。实际上，有一个MSDN页面涵盖了这个。
你要找的是一种多解决方案方法，类似于用于较大系统的分区单解决方案模型。有一个“所有内容”解决方案，它可以构建所有内容并维护您的组件间依赖关系。当您需要构建解决方案A时，就构建它。然后，您有单独的解决方案，只包括组件B或C。基本上，您仍然有3个解决方案，但是您将从解决方案B和C中添加项目到解决方案A中。
你要找的是一种多解决方案方法，类似于用于较大系统的分区单解决方案模型。有一个“所有内容”解决方案，它可以构建所有内容并维护您的组件间依赖关系。当您需要构建解决方案A时，就构建它。然后，您有单独的解决方案，只包括组件B或C。基本上，您仍然有3个解决方案，但是您将从解决方案B和C中添加项目到解决方案A中。
- Greg D
2
3这个模型也存在问题。例如，TFS(-2012)仍然不够智能，无法意识到如果您在一个解决方案的上下文中重命名项目，则包括该项目的任何其他解决方案也需要更新（在sln文件中的“引用”）。此外，在现实世界中，您可能会使用最新的开发工具（VS-2012）来完成大部分工作，但仍然需要在另一个工具中开发解决方案的某些部分（例如BizTalk，在我所知道的情况下仍然无法在VS-2012中进行），因此“完整”的解决方案不可行。 - The Dag
在这种情况下，您只需使用完全分区的模型和自定义构建系统即可。 :) 这并不是一个罕见的情况。 - Greg D
4
我最近发现，在Visual Studio 2008中，您可以在多个解决方案中包含现有项目。到目前为止，唯一的缺点似乎是，如果您对共享项目进行更改并且打开使用该共享项目的多个解决方案，则会被要求“重新加载”其他解决方案。
因此，只需将“现有项目添加”到需要该项目的所有解决方案中即可。我在当前站点上使用TFS，看起来源代码控制没有问题。
- Paul Redman
3
我认为您需要查看项目级别。首先构建解决方案B和C中包含的项目，然后在解决方案A中的相关项目中添加对DLL的引用。
在Msbuild中，如果您有一个属性组，请注意：
希望这能帮到你。
在Msbuild中，如果您有一个属性组，请注意：
<PropertyGroup>
<SolutionsToBuild>SolutionB</SolutionsToBuild>
<SolutionsToBuild>SolutionC</SolutionsToBuild>
<SolutionsToBuild>SolutionA</SolutionsToBuild>
</PropertyGroup>
然后执行MSBuild任务
<MSBuild Projects="@(SolutionsToBuild)"/>
希望这能帮到你。
- Dean
1
您可以尝试自动化合并过程以节省时间： http://code.google.com/p/merge-solutions/
虽然我们遇到了略微不同的问题：大约有15个解决方案（总共约150个项目）使用一个公共库。问题在于，如果我们尝试将它们全部合并为一个，以便从公共库中重构/消除冗余代码。 1. 合并15个解决方案需要在VS中进行大量点击和等待 2. 生成的解决方案从未更新-由于其大小，没有人费心更新它
- bushed
0
我通过将脚本放在预构建事件命令行中来解决了这个问题，如果项目A无法构建，则抛出消息警报。
ECHO "build A project"
set AppMsg ="%SystemRoot%\System32\msg.exe"
set AppMsg
if not "%ProgramFiles(x86)%" == "" (
if exist "%SystemRoot%\Sysnative\*" set AppMsg="%SystemRoot%\Sysnative\msg.exe"
)
set AppMsg
taskkill /f /im "%PROGRAMFILES(X86)%\MSBuild\14.0\Bin\msbuild" "$(SolutionPath)" /t:Project_A_Name /p:Configuration=Debug;TargetFrameworkVersion=v4.5 /p:Platform="Any CPU" /p:BuildProjectReferences=false /p:VSToolsPath="%PROGRAMFILES(X86)%\MSBuild\Microsoft\VisualStudio\v14.0" 2>nul 1>nul
echo ERRORLEVEL %ERRORLEVEL%
if ERRORLEVEL 1 (
ECHO "failed to build test project"
%AppMsg% * "failed to build test project"
)
exit 0
- Yitzhak Weinberg
0
根据this answer，我建议您创建自己的批处理文件，它将为您构建相关的解决方案。
这非常方便使用，因为构建过程将为每个构建执行输出构建进度（类似于Visual Studio中的输出窗口）到命令提示符。
此外，在需要先构建一个解决方案再构建另一个解决方案的情况下，您可以编写自己的构建顺序，例如：
敬礼。
这非常方便使用，因为构建过程将为每个构建执行输出构建进度（类似于Visual Studio中的输出窗口）到命令提示符。
此外，在需要先构建一个解决方案再构建另一个解决方案的情况下，您可以编写自己的构建顺序，例如：
- 构建B解决方案
- 构建C解决方案
- 构建A解决方案（其中内部使用“解决方案B”和“解决方案C”构建文件）
敬礼。
- Eido95
1
0
你可以尝试在解决方案A的预构建事件中添加依赖于解决方案B和C中dll的命令行构建命令。
- Brann
0
如果您无法将项目B和C放入与项目A相同的解决方案中，则无法确保在构建项目A时包含最新源代码的B和C二进制文件。
我看到的最简单的解决方案是在源代码存储库中有一个公共文件夹，每个项目都会将其二进制文件复制到该文件夹中（如果需要共享）。然后，所有其他项目都可以引用该文件夹中的二进制文件，只要您的本地文件夹看起来与存储库相同即可。
这不是完美的解决方案，但很容易使用。
- user16324
0
你可以将一个 Makefile 项目添加到解决方案 A 中，该项目将使用 msbuild 构建你的解决方案 B 和 C，并使 A 中的所有项目依赖于该 Makefile 项目。这样你就无法向 B 和 C 中的项目添加项目引用，但可以使用 dll 引用，它们将始终从最新的源代码构建。
- Juozas Kontvainis
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接