我正在使用BizTalk 2013解决方案,并且我正在努力发展自动化测试。但是,当我尝试在仅更改测试项目之后运行我的测试,或者甚至在任何地方都没有更改之后运行测试时,我在构建当我在上面调用完全重建时构建的相同数量的项目正在测试的项目。这花费了大量的时间,而且因为我将未来的投资卖给这种类型的东西而被判死刑。
这是BizTalk的一个已知缺陷,还是与MSBuild的交互?这是我可以修复的已知陷阱吗?
编辑:在审核了"可能重复的"线程,我相信这个问题是相似的,但是截然不同。该主题的解释突出了MSBuild确定需要重建的机制,但MSBuild是Visual Studio中所有项目中广泛使用的技术,并且可能因项目类型的显着不同而基于该项目类型的特定目标导入。我编辑了问题标题,以反映我想学习如何为BizTalk解决方案预防这种情况,而不是简单地询问它为什么会发生(虽然知道为什么总是有用)。
答案 0 :(得分:3)
所以,你所看到的并不是BizTalk的问题(因为BizTalk是完美而精彩的,从来没有任何问题......)。
这实际上是Visual Studio的一种行为。需要注意的是,BizTalk Projects只是专门的c#项目。
我一直在做的最好的解决方法是取消选中我在解决方案配置中没有积极使用的项目的构建和部署选项。如果未检查Project的Build,即使选择Rebuild Solution也不会构建。
答案 1 :(得分:2)
一种可能的解决方案是不引用项目,而是引用相同的DLL文件 - 已经编译和构建的项目。
这样,在构建测试项目时,它将针对这些现有程序集构建,因此不会花时间重建这些程序集。
但是,必须确保这些DLL在其后面的项目也更新时进行更新。您可以通过在必要时在单独的Visual Studio实例中重建它们来完成此操作。
需要一些练习和思考,以确保您正在构建最新版本,但它会为您节省大量时间。
答案 2 :(得分:2)
我也注意到了这一点。打开MSBuild上的诊断输出,结果发现项目设置.user
文件在.pdb
文件后被修改。我已经尝试了几种解决方法,包括更改pdb文件的修改日期,将.user文件设置为readonly,删除(重命名).user文件等。
不幸的是,BizTalk的构建任务将在每次构建后覆盖/重新创建/创建新的.user文件,而我还没有想出一种方法来说服MSBuild它可以忽略.user文件创建为新的。因此,我会在这里提出其他建议之一。
甚至在文件上创建一个独占锁,以便MSBuild无法更新它会导致重建,因为MSBuild认为构建是脏的(" Project' Schemas'不起来到目前为止。在MSBuild中项目很脏。")