Visual Studio 2008，MSBuild：“替换”项目

我的解决方案有一个需要构建特殊环境（大量外部库和工具）的库项目......但它对于我们的应用程序并不重要。我们希望避免在不需要的情况下安装这些工具（大多数开发人员在其他代码部分工作）。Visual Studio 2008，MSBuild：“替换”项目

我们已经创建了另一个具有相同API但具有空实现的项目，并且可以在没有这些外部工具的情况下进行编译。我希望能够轻松地在这些项目之间进行切换，并仍能正确地获取其他项目中的所有参考。

我不知道VS/MSBuild很好，但愿意学习任何必要的。可能吗？我正在寻找想法......我们正在使用Subversion，并且也欢迎涉及VCS内部一些攻击的解决方案。

来源

2010-05-24 liori

听起来好像您的图书馆项目是一个可以从您的主要解决方案中分离出来的项目，并带上了工具包。这样做，您可以单独构建专业解决方案，从主解决方案链接编译好的程序集。

来源

2010-05-24 23:43:11

我们非常希望将它作为我们主要解决方案的一部分（这简化了持续集成设置），但如果没有其他想法，我会考虑您的。谢谢。 – liori 2010-05-25 00:05:10

@liori如果外部依赖关系采用库和独立工具的形式，则可以将这些添加到源代码管理中，并根据需要引用它们。这将避免需要任何“特殊设置”。 – 2010-05-25 20:19:16

为便于讨论，我假定您有一个包含解决方案文件的项目目录，一个“RealLibrary \ RealLibrary.csproj”项目文件（您的“真实”库和依赖项）以及一个“MockLibrary \ MockLibrary”。 csproj“文件（你的”模拟“库，空实现）。

如果我理解正确的，你想轻松地“交换”在解决方案中的MockLibrary为RealLibrary，反之亦然。

假设您的解决方案（和相关项目）配置为查找“RealLibrary.csproj”项目，最简单/最诡异的方法是重命名“RealLibrary”目录（这与什么无关），并将“MockLibrary”目录重命名为“RealLibrary”，并将“MockLibrary.csproj”重命名为“RealLibrary.csproj”。这将有效地“欺骗”您的解决方案和相关项目，即使它们正在引用“真正的库”，也会加载“模拟库”。

一个稍微复杂一点的解决方案实际上是修改“sln”和“csproj”文件以引用“MockLibrary.csproj”而不是“RealLibrary.csproj”。在“SLN”的文件，你需要将路径更改为项目的部分靠近顶部：

Microsoft Visual Studio Solution File, Format Version 10.00 
# Visual Studio 2008 
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}" 
EndProject

您需要更改路径“RealLibrary \ RealLibrary.csproj”到“MockLibrary \ MockLibrary .csproj的”。如果你要完整，你也可以改变名称（或者可能只是使用一个通用名称，比如“库”作为名称）。

同样，在相关的csproj文件，你需要找到“ProjectReference”节点的所有情况下，您引用“RealLibrary.csproj”和修改路径。这些部分如下所示：

<ProjectReference Include="..\RealLibrary\RealLibrary.csproj"> 
    <Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project> 
    <Name>RealLibrary</Name> 
</ProjectReference>

您可以相对轻松地编写一些脚本来执行此交换。但是，我认为这里有一个更深层的问题，可以更直接地解决。我会把它作为一个单独的答案发布，但我希望你能够首先找到你正在寻找的实际答案。

来源

2010-05-25 19:00:45

我想我必须在任何时候撤消重命名'svn update'？ – liori 2010-05-25 20:47:45

是的，用我的第一种方法可能会导致一些svn灾难。第二个不是很糟糕，但你仍然遇到这些sln/csproj文件冲突的可能性。如果您的意图是开发人员通常使用“模拟”库，那么我会使用该库将解决方案检查为svn，并使用CI中的预构建脚本交换“真实”库。如果开发人员需要使用“真实”库，开发人员可以特别运行该脚本。 – 2010-05-26 13:50:46

更深层次的问题，我在这里看到的是，你的图书馆“需要建立一个特殊的环境”，特别是因为它取决于“很多外部库和工具”。我建议你不要去创建模拟库的路径，而是专注于让库在没有特殊环境的情况下正确构建。您可以通过将所有这些依赖包括在您的项目中并包含在源代码控制中来实现此目的，并通过工作副本中的相对路径引用这些依赖项。在我的构建环境中，尽量避免静态环境依赖（理想情况下仅限于.NET框架本身）。

要将依赖项放到源代码控制中，可以直接将它们检入项目本身，也可以将它们检入不同的位置，然后通过svn:external定义在项目中“引用”它们。在我的环境中，我有一个单独的“bin”存储库，仅用于这些类型的第三方库依赖项，然后许多依赖项目可以通过外部程序将其引入。

如果您可以消除库的构建时环境依赖性，那么构建将会更加健壮，开发人员将更容易使用该项目。

来源

2010-05-25 19:08:27

这些库/工具具有昂贵的每席位许可证，安装后需要大约10GB的空间，并且需要适当的安装才能运行（一些疯狂的科学软件）。我对此没有影响。尽管我们已经使用svn：external来处理一些较小的库。 – liori 2010-05-25 20:44:47

够公平 - 那完全合法。你有这些限制太糟糕了，但有时你无法绕过它们。鉴于此，我看到了三种选择：1）单独编译你的库并在下游项目中引用已编译的二进制文件（@Grant Palin），2）交换项目，如我在其他答案中所描述的那样，3）维护两个单独的解决方案（不是很有吸引力）。 – 2010-05-26 13:47:15

为您的项目创建另一个构建配置。所以你至少要有2个构建配置，例如Debug_SpecialNeeds和Debug。

来源

2010-10-20 18:21:00 Yatin

在Visual Studio中，托管项目中的引用不能针对每个构建配置给出。我修改了MSBuild文件以在引用上添加条件（在我的情况下取决于系统中某些文件的存在），但VS似乎忽略了它们，并为实际和模拟项目提出了警告/错误。 – liori 2010-10-20 21:13:01

Visual Studio 2008，MSBuild：“替换”项目

回答

相关问题