MSTest：从公共目录部署项目的合理方法？

最近在处理DeploymentItem时，我掉了几根头发

我们有一些本机dll的通用目录，许多测试都依赖于这些目录

<>对于C++项目，我们使用属性类型，其中定义了这些路径。这些文件甚至可以通过一些手动编辑（因为它们是MSBuild文件）导入到C#项目中。我仍然不知道如何在测试中使用它们

不幸的是，DeploymentItemAttribute不能使用工作表中的属性，但它可以利用环境变量。我希望避免强迫每个人定义全球环境变量

我在网上看到了各种各样的建议，但还没有找到一个简单的解决方案

---

有人对此有很好的方法吗？

如果这些是仅由该项目使用的外部依赖项（不在源代码树之间共享），那么我建议将它们移到源代码管理中。依赖项应与源一起进行版本控制。其基本原理是，您应该能够签出源代码树的修订版（历史记录中的任何修订版），并且应该构建源代码树。如果您有不受源代码管理的二进制依赖项，那么在生成特定版本的源代码时，您将很难知道需要哪个版本的依赖项

如果您可以将依赖项移动到源树中（例如$svnroot/trunk/dependencies），那么您可以使用仅具有相对路径的测试部署。它将在TeamCity以及任何开发人员机器上工作

如果无法对依赖项进行版本设置，或者由于其他原因必须将它们放在存储库之外，则可以使用测试部署可以使用的环境变量。看

编辑：将有关管理二进制依赖项的注释移到此处

---

对于csprojs，我在项目中有一个dll引用，指向源代码树下lib目录中的dll:s（即引用..\lib\log4net.dll）。如果要为单独的生成引用单独的lib，例如，对于x86/64或Debug/Release，则VS不支持它，但MsBuild和csproj文件支持它，因此，您可以添加条件引用，但必须手动编辑csproj，以便仅在平台为x86等情况下包含x86依赖项。

Anders的答案是一个很好的解决方案，但在我的情况下：

我不喜欢在源代码树中保留二进制文件的想法

许多DLL没有特定的版本，并且定期更新 基础

我以某种方式得到了这个解决方案：

首先，我在测试项目中包含了全局VC++属性页。必须通过在.csproj顶部的

标记下添加此指令手动完成此操作：

我现在访问了在C++环境中定义DLL路径的属性/宏。 我那么

在测试项目中添加了一个新的子文件夹，例如

“nativedells”

将所需的DLL作为链接添加到NativeDell文件夹中

这些链接是绝对链接，但可以替换为来自 上述财产清单包括：

nativedells\mylib.dll

然后，DLL就可以部署了：

[TestMethod]
[DeploymentItem(@"NativeDlls")]
public void TestSomeStuff()
{
}

而且，正如Anders提到的：剩下的工作是设置调试/发布和32/64条件。
这些“公共目录”不能存在于所有其他资源的已知相对路径中（即，在源代码树中）？我就是这样做的。如果一个构建应该能够在没有外部人工制品的情况下签出/构建/测试，那么您必须在源代码树中保留本机依赖项。不幸的是，这不起作用。其中一个原因是我们使用TeamCity进行构建。TC决定在哪里签出源代码树。我不明白，在哪里签出源代码树无关紧要？如果依赖项都在源代码树中，并且deploymentitems都使用相对路径，会发生什么？在TeamCity的情况下：TC创建一个新的签出目录，并且在build agents工作目录下生成目录名。例如：D:\TeamCity\buildAgent\work\1cadee32327408f3\因此，无法知道DLL在哪里。TC这样做的原因可能是版本处理之类的。从公共目录而不是源目录树进行部署还有其他原因；这里的其他开发人员只是从公共存储库获取最新版本。是的，如果您想从源目录之外的存储库获取DLL，那么您将在创建临时工作目录时遇到问题。但我只讨论源代码树中对dll:s的相对引用，也就是说，在TC创建的工作目录中。