DeploymentItem属性的问题

我目前正在维护用C＃.net编写的“旧”系统，删除一些过时的function并进行一些重构。 感谢上帝，前面的人写了一些unit testing（MSTests）。 我对JUnittesting非常满意，但是对于MSTests还没有做太多的工作。

testing方法有一个DeploymentItem属性，用于指定一个文本文件，该文件由正在testing的业务逻辑方法进行parsing，第二个DeploymentItem只包含一个包含一堆必须部署的TIF文件的path。

 [TestMethod()] [DeploymentItem(@"files\valid\valid_entries.txt")] [DeploymentItem(@"files\tif\")] public void ExistsTifTest() { ... } 

之前的testing工作，但现在我不得不改变\ files \ tif目录中包含的TIF文件的名称。 根据规则，TIF文件名必须与ExistsTifTest()方法检查的特定模式相匹配。 现在我不得不改变文件名以适应新的要求，突然之间TIF文件就不再像以前那样部署了。

有人可以给我一个暗示为什么会发生这种情况，或者是什么原因？ 同样的事情也会发生，如果我添加一个新的文本文件，并在\ files \ valid \目录中的“valid_entries.txt”旁边添加“my2ndTest.txt”，并在test方法中使用相应的DeploymentItem属性。 该文件没有被部署？

我通过直接在testrunco​​nfig中定义部署path，得到了现在部署的映像，但我想了解为什么发生这些事情，或者为什么我的新文件“my2ndTest.txt”没有得到部署，而其他人做。

Answer 1

DeploymentItem有点乱。

您的解决scheme中的每个文件都将在VS.NET中具有“复制到输出文件夹”设置。 您需要将其设置为“始终复制”（或类似）才能将文件导入到输出文件夹中。

检查你是否有这个新的文件集。 如果你没有这个设置，那么文件将不会被复制到输出文件夹，然后他们不能被从输出文件夹部署到MSTest的东西的文件夹。

就个人而言，如果我有unit testing需要的文件，我发现将这些文件作为资源embedded到程序集中，并在testing期间让程序本身“解压缩”是一种更可预测的方式。 因人而异。

注意：这些评论是基于我对VS2010的经验。 对我的回答的评论意味着这不是VS2012的问题。 我仍然坚持认为，使用embedded式资源涉及较less的“魔力”，对我来说，使unit testing的“安排”阶段更加明确。

Answer 2

在VS2010中，我的Local.testsettings的“启用部署”未选中，DeploymentItem属性不起作用。 我检查了一切正常。 我希望这有帮助！

Answer 3

我也面临类似的问题，但我发现这个简单的3步解决scheme：

假设您的文件夹结构如下所示： SolutionFolder\ TestProjectFolder\ SubFolder\

1. 转到“解决scheme项目/本地.testsettings”>“部署”>选中“启用部署”
2. 如果您使用的是VS2010，请确保您要部署的任何文件的“复制到输出文件夹”属性设置为“始终复制”或“如果新build复制”
3. 使用以下任何一种方法将TestMethod属性赋值：
   • [DeploymentItem(@"TestProjectFolder\SubFolder")]将<SubFolder>所有内容部署到Test Run目录
   • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")]将testing运行目录中<SubFolder>所有内容部署到<TargetFolder>

关于MSTest的最后一个注意事项（至less在VS2010中）：

如果您希望<TargetFolder>具有与<SubFolder>相同的名称，那么使用[DeploymentItem(@"SubFolder", @"SubFolder")]将会在MSTest runner遇到愚蠢的边界情况时失败。 这就是为什么你应该使用<TestProjectFolder>作为前缀<SubFolder> ： [DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Answer 4

如果进入.testrunco​​nfig文件，并在部署下取消选中“启用部署”，则testing将在正常位置运行，并且在unit testing之外运行应用程序时，所有操作都将如常进行。

Answer 5

希望帮助其他人：我在这里尝试了所有的build议， 仍然没有复制我的部署项目。

我所要做的（ 如这里所build议的 ）是向DeploymentItem属性添加第二个参数：

 [DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")] 

Answer 6

这可能并不涉及到你确切的问题，但是这里有一些关于[DeploymentItem]属性的技巧。

1. 复制到输出目录应设置为始终复制。

与[TestInitialize]属性一起使用时不起作用

 [TestInitialize] [DeploymentItem("test.xlsx")] public void Setup() { 

它应该在你的[TestMethod]上，例如

  [TestInitialize] public void Setup() { string spreadsheet = Path.GetFullPath("test.xlsx"); Assert.IsTrue(File.Exists(spreadsheet)); ... } [TestMethod] [DeploymentItem("test.xlsx")] public void ExcelQuestionParser_Reads_XmlElements() { ... } 

Answer 7

不知道这是否完全回答这个问题，但它可能会有所帮助。 首先，我发现必须选中“启用部署”框才能部署工作。 其次，文档说源path是“相对于项目path”，起初我是指项目文件夹。 实际上，它似乎是指编译输出文件夹。 所以，如果我有一个名为“TestFiles”的项目文件夹和名为Testdata.xml的文件，使用这种方式的属性不起作用：

 [DeploymentItem(@"TestFiles\Testdata.xml")] 

我可以将Testdata.xml文件标记为“ Copy Always ，以便构build将副本放在输出文件夹下（例如， Debug\TestFiles\TestData.xml ）。 然后部署机制将查找位于该path（ TestFiles\Testdata.xml ）相对于生成输出的文件的副本。 或者，我可以这样设置属性：

 [DeploymentItem(@"..\\..\TestFiles\Testdata.xml")] 

部署机制将find原始文件。 所以要么是有效的，但我已经注意到使用Copy Always我偶尔会遇到同样的问题，当我编辑项目中的app.config文件 – 如果我不改变代码或强制重build，没有触发文件的复制标记为在构build时被复制。

Answer 8

在尝试所有其他build议后，我仍然无法弄清楚发生了什么事情。 最后我发现Test / Test Settings菜单下没有select设置文件，这意味着Deployment没有被启用。 我点击testing/testing设置/selecttesting设置文件菜单项，selectLocal.TestSettings文件，然后一切正常。

Answer 9

我有先禁用部署标志。 但即使启用它，由于某些未知的原因，即使目标DLL也不会被复制。 不小心，我打开了testing运行窗口，并杀死了所有以前的运行，神奇地，我发现所有的DLL和文件我需要在testing文件夹下一次运行…非常混乱。

Answer 10

我在尝试获取文件时遇到了很多问题 – 尝试了上面的所有build议。

然后我closuresVS2010; 重新启动它，加载解决scheme，一切正常。 （！）

我做了一些检查; 在local.TestSetting上设置“启用部署”标志之后，不应该简单地从“testing结果”窗口重新运行testing。 您必须从UI中删除以前的testing运行，例如通过运行不同的testing或重新打开解决scheme。

Answer 11

由于我总是发现DeploymentItem属性乱七八糟，所以我通过使用后生成脚本来部署这些文件。 – 确保要复制的文件具有“始终复制”属性设置。 – 修改testing项目构build脚本，将文件从构build目标文件夹（Bin \ Debug）复制到testing期望的位置。

Answer 12

试试这个VS2010。 所以你不需要为每个tif添加DeployItems
去除

 [DeploymentItem(@"files\valid\valid_entries.txt")] [DeploymentItem(@"files\tif\")] 

添加testingconfiguration。
– 在解决scheme资源pipe理器中右键单击解决scheme节点
– 添加 – >新build项目…
– select左侧的testing设置节点，select右侧的项目
– 点击添加

称之为TDD

在Edit Testsettings > Edit Testsettings下selectTDD 。

点击部署。 启用它，然后添加所需的文件和目录。将有相对于解决scheme的path。 这些文件将被放置。 原始文件例如在这里：

 D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml 

当我运行我的unit testing时，它被复制到

 D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Patrik_HERKULES 2011-12-17 18_03_27\Authority.xml 

在testing代​​码中，我从下面来调用它：

 [TestMethod()] public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary() { string authorityFile = "Authority.xml"; var Xmldoc = XDocument.Load(authorityFile); 

没有必要select总是复制; 把文件放在testproject中; 在testing代​​码中添加硬编码path。 对我来说，这个解决scheme最好。 我尝试了DeploymentItem，总是复制，但它不是我喜欢的。

Answer 13

我在VS2013中一直在做这个工作。 我的发现得到这个工作：

• 复制到输出目录应设置为始终复制：强制。
• .TestSettings中的“启用部署”：不是必需的。 我得到这个工作，没有.TestSettings文件。
• 指定一个文件夹作为第二个参数：可选。 形成输出文件夹布局，没有工作正常。
• 空间中的文件名：这让我头痛 – 文件从未被复制过。 删除的空间解决了这个问题。 还没有查看转义字符。

一个提示我也学会了艰难的方式：不要忘记添加这个属性到每个单独的testing。 该文件在testrun中的第一个属性testing上复制，但是当testing顺序发生变化并且非属性testing首先尝试查找文件时，该文件仍然丢失。

Answer 14

对于那些喜欢避免DeploymentItem的混乱，并采取@Martin Peckbuild议的方法（接受的答案），您可以使用下面的代码来访问embedded式资源的内容：

 public string GetEmbeddedResource(string fullyQulifiedResourceName) { var assembly = Assembly.GetExecutingAssembly(); // NOTE resourceName is of the format "Namespace.Class.File.extension"; using (Stream stream = assembly.GetManifestResourceStream(fullyQulifiedResourceName)) using (StreamReader reader = new StreamReader(stream)) { string result = reader.ReadToEnd(); } } 

有关详细信息，请参阅此线程

Answer 15

我的大“陷阱”是DeploymentItem处理目录的方式。 我正在使用两个参数版本作为目录path包含我想部署的子目录。 我最初并没有意识到它只是复制了目录ROOT中的东西，而不是整个recursion的文件夹结构！

我基本上有[DeploymentItem（@“Foo \”，@“Foo \”）]，并期待它部署我的Foo \ Bar。 我特别不得不把它改成[DeploymentItem（@“Foo \ Bar \”，@“Foo \ Bar \”）]，现在它就像一个魅力。

Answer 16

我也面临类似的问题。 我有上面提到的所有步骤，但仍然没有运气。 我正在使用VS2010。 然后我发现$ Menu> Test> Select Active Test Setting> Trace and Test影响被选中。 它开始工作后，我更改跟踪和testing影响本地 。 这个页面包含有关将文件复制到testing结果文件夹的非常丰富的信息，我觉得也要添加这个经验。

Answer 17

对我来说，根本原因是完全不同的：我的testing正在执行的产品代码是重命名和/或删除正在部署的.xmltesting文件。

因此，当我单独运行我的testing时，它们会通过，但是当它们一起运行时，第二个和后续testing将会以“文件未find”错误（我最初被误诊为DeploymentItem属性不起作用） 。

我的解决scheme是让每个单独的testing方法复制已部署的文件（使用此技术 ），然后让正在testing的生产代码使用复制的文件而不是原始文件。

Answer 18

我们花了很多时间用部署项目的问题来解决它，在本地unit testing运行和teamcityunit testing也是如此。 这不简单。

debugging这个问题的很好的工具是ProcessExplorer 。 使用进程资源pipe理器，您可以检查Visual Studiosearch部署项目的位置，并对项目进行更正。 只要筛选path包含您的deploymentitem文件名的所有文件操作，您就会看到它。

Answer 19

除了Deployment属性需要检查之外，我还发现了有关DeploymentItem属性的其他内容。

 [TestMethod()] [DeploymentItem("fodler\subfolder\deploymentFile.txt")] public void TestMethod1() { ... } 

您的deploymentFile.txt需要与解决scheme文件关联，而不是testfile.cs。

Answer 20

不要使用DeploymentItem 。

这是很难正确设置，它不与我的ReSharpertesting亚军，也没有Visual Studio 2017 MSTEST的本机之一。

相反，请右键单击您的数据文件，然后select属性 。 select复制到输出目录：始终 。

现在在你的testing中，做到这一点。 该目录就是相对于testing项目的文件目录。 简单。

  [TestMethod()] public void ParseProductsTest() { // Arrange var file = @"Features\Products\Files\Workbook_2017.xlsx"; var fileStream = File.Open(file, FileMode.Open); // etc. } 

警告。 我不知道这是否适用于自动化的构build和testing系统。 我还没有呢。