在使用moles程序集的项目上使用TFS2010构建会失败，并显示-1002，因为无法解析引用
经过多次尝试，我成功地让 TFS 能够在除测试项目之外的所有项目上运行构建。这些里面有一个鼹鼠组件。
我收到的错误是
C:\Program Files\Microsoft Moles\bin\Microsoft.Moles.targets (79):
命令“C:\Program Files\Microsoft Moles\bin\moles.exe”
@"C:\Builds\2\cv2\DevBranchBuild\Sources\CV.BL.Tests\obj\Release\Moles\moles.args""
退出，代码为-1002。
警告是
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1360):
无法解析此引用。
无法找到程序集“CV.DAL.Moles，版本=1.0.0.0，文化=中性，处理器架构=MSIL”。
检查以确保程序集存在于磁盘上。
如果您的代码需要此引用，您可能会遇到编译错误。
CV.DAL 是我正在修改的程序集。
我正在使用最新版本的pex和moles。
我还将 CV.DAL.moles 文件签入 TFS（而不是程序集）。 一切都在我的本地机器上完美构建。我用来构建的机器具有完全相同的配置。确切地说，我的意思是一个是 32 位，另一个是 64 位：o（严重疏忽）。
有什么想法吗？
这使得 pex 和鼹鼠完全无用，因为它在合并分支时破坏了门控签入，这是一个巨大的耻辱，因为我在它们上投入了大量的时间。
编辑哪些molesAssemblies目录？ 摩尔的安装文件夹还是项目下的目录？
两台计算机上的安装文件夹具有相同的文件和文件大小。
After much playing i have managed to get TFS to be able to run builds on all of my projects except the test projects. These have a moles assembly in them.
The errors i am getting are
C:\Program Files\Microsoft Moles\bin\Microsoft.Moles.targets (79):
The command ""C:\Program Files\Microsoft Moles\bin\moles.exe"
@"C:\Builds\2\cv2\DevBranchBuild\Sources\CV.BL.Tests\obj\Release\Moles\moles.args""
exited with code -1002.
The warning is
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1360):
Could not resolve this reference.
Could not locate the assembly "CV.DAL.Moles, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL".
Check to make sure the assembly exists on disk.
If this reference is required by your code, you may get compilation errors.
CV.DAL is the assembly i am moling.
I am using the latest version of pex and moles.
I also have the CV.DAL.moles file checked into TFS (not the assembly).
Everything builds perfectly fine on my local machine. The machine I am using to do the builds has exactly the same configuration. By exactly I mean that one is 32 bit and the other is 64 bit :o (serious oversight there).
Any ideas?
This makes pex and moles utterly useless as it is breaking gated checkins when merging branches which is a great shame as i invested a decent amount of time into them.
EDIT
Which molesAssemblies directories?
The install folder for moles or the directories under the project?
The installation folder has he same files and file sizes on both machines.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能是两个问题之一 - 我前段时间遇到了这两个问题：（
一）您的依赖项之一被标记为 32 位。这可能是 cv.dal.dll 或其任何依赖项。 Moles.exe 必须加载程序集才能执行 - 不确定为什么它不使用 Load.ReflectionOnly - 并且由于 moles.exe 是 ILONLY，因此它在 64 位计算机上作为 64 位进程执行。这使得摩尔生成失败。
解决方法是将moles.exe 设置为仅32 位：
（二）如果您使用并行构建（例如，在您的 .msbuild 文件中，您有选项 BuildInParallel="true" ，或者您使用选项 /m 运行 msbuild.exe）并且您在您的单元中创建摩尔测试项目的 PreBuildEvent，那么您将遇到 msbuild 目标的问题。 PreBuildEvent 在解析引用之前执行，并在解析引用时检查跨项目依赖关系，因此您的 PreBuildEvent 有可能在依赖项目完成构建之前开始执行。
对此没有好的解决方法。您可以使用非并行构建（这将使您的构建速度变慢），也可以将预先生成的 *.moles.dll 签入源代码管理（每次接触 moled 程序集时都必须维护和更新）。
This could be one of two problems -- I ran into both of them some time ago:
(one) One of your dependencies is marked as 32 bit. This might be cv.dal.dll or any of its dependencies. Moles.exe has to load assembly for execution -- not sure why it does not use Load.RefrectionOnly -- and since moles.exe is ILONLY, it executes as 64 bit process on 64 bit machine. This makes moles generation fail.
The workaround for that is set moles.exe to be 32 bit only:
(two) If you use parallel build (e.g. in your .msbuild file you have option BuildInParallel="true" , or you run msbuild.exe with option /m) AND you create moles in your unit test project's PreBuildEvent, then you will run into problem with msbuild targets. PreBuildEvent executes before references are resolved, and check for cross-project dependencies are done at the time of resolving references, so there is a chance that your PreBuildEvent will start executing before dependent projects finished building.
There is no good workaround for that. You can either use non-parallel build (which will make your build slower) or you can check in pre-generated *.moles.dll into source control (which you will have to maintain and update every time you touch your moled assembly).
旧版本的 Moles 曾经也存在类似的问题。将disableCache =“true”添加到.moles文件修复了这些问题：
http://social.msdn .microsoft.com/Forums/en-US/pex/thread/a6d9a67b-0813-4392-a5dd-bea6eb479eea
There used to be a similar issue with older versions of Moles. Adding disableCache="true" to the .moles file fixed those issues:
http://social.msdn.microsoft.com/Forums/en-US/pex/thread/a6d9a67b-0813-4392-a5dd-bea6eb479eea