2

最近在尝试处理 DeploymentItem 时，我失去了一些头发。

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

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

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

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

有人对此有好的方法吗？

4

2 回答 2

2

安德斯的回答是一个很好的解决方案，但就我而言：

  1. 我不喜欢将二进制文件保存在源代码树中的想法
  2. 许多 dll 没有特定版本，它们会定期更新。

我以某种方式结束了这个解决方案：

首先，我将全局 VC++ 属性页包含在测试项目中。这必须通过<Project>在 .csproj 顶部的标记下添加此指令来手动完成：

<Import Project="$(UserProfile)\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props" />

我现在可以访问在我的 C++ 环境中定义 dll 路径的属性/宏。

我那时

  1. 在测试项目中添加了一个新的子文件夹，比如说"NativeDlls"
  2. 将所需的 dll 作为链接添加到 NativeDlls 文件夹中
  3. 链接是绝对的，但可以用上面包含的属性表中的宏替换：

<Content Include="$(MyLibLocation)\GDAL18BIN\gdal18.dll">

<Link>NativeDlls\mylib.dll</Link>

<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>

</Content>

然后 dll 就可以部署了：

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

而且，正如 Anders 所说：剩下的工作是设置调试/发布和 32/64 条件。

于 2012-06-20T12:45:59.880 回答
1

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

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

如果您无法对依赖项进行版本控制，或者由于某些其他原因必须将它们放在存储库之外，那么您可以使用测试部署可以使用的环境变量。有关示例，请参阅此 msdn 帖子

编辑：在此处移动了有关管理二进制依赖项的评论

对于 csprojs，我只是在项目中有一个 dll 引用，指向源树下 lib 目录中的 dll:s（即对 ..\lib\log4net.dll 的引用）。如果您想为单独的构建引用单独的库，例如 x86/64 或 Debug/Release 不同，那么 VS 不支持它，但 MsBuild 和 csproj 文件支持，因此您可以添加条件引用但您必须编辑 csproj仅当平台为 x86 时手动包含例如 x86 依赖项，依此类推。

于 2012-06-20T10:22:59.027 回答