“随机”使用 VS2008 devenv.exe 在命令行构建 Biztalk 2009 解决方案时出现 .NET 运行时错误
为了将 Biztalk 2009 项目构建为 TFS 2010 团队构建的一部分,我使用 MSBuild exec 任务来 shell 到 VS2008 devenv.exe,如下所示...
<Exec Command=""$(BuildMachineLoc)devenv.exe" "$(BiztalkSolutionPath)" /Build "$(BuildFlavor)" /out "$(DropLocation)\$(BuildNumber)\CoreBiztalkBuildOutputLog.txt""/>
这在 95% 的时间里都能正常工作。但是,构建会随机失败,并在日志中显示以下错误。 (我对此进行了稍微编辑,以省略我正在构建的服务的名称)
Build FAILED.
MSB3073: The command ""C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "[path to my solution]" /Build "Release" /out "[path to my drop location]\CoreBiztalkBuildOutputLog.txt"" exited with code -2146233082.
如果您检查 CoreBiztalkBuildOutputLog.txt 文件,它会显示一切都已成功构建。如果您将失败构建的日志与成功构建的日志进行比较,它们是相同的。
代码-2146233082不是很有描述性...所以我从构建机器上的事件查看器中找到了实际的异常。
Event Type: Error
Event Source: .NET Runtime
Event Category: None
Event ID: 1023
Date: 2/17/2012
Time: 2:58:41 AM
User: N/A
Computer: XXXXXXXX
Description:
.NET Runtime version 2.0.50727.3625 - Fatal Execution Engine Error (7A0BC59E) (80131506)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
在网上查了一下表明这是某种 CLR 错误。建议的解决方案是重新安装\修复 .NET 框架。这似乎是有道理的,因为我之前使用的构建机器是一台 7 岁的恐龙,自从我拥有它以来,它就一直存在各种问题。 (大约 2 年)
我最终配置了一个新的 VM 来运行我的 Biztalk 2009 版本,这样我就可以完全淘汰旧的物理服务器。然而,令我懊恼的是,我发现大约 5% 的时间我在新服务器上遇到同样的随机 CLR 错误。
基于此,我猜测这是 .NET 框架中的某种缺陷,我无法修复。但如果有人有任何想法,我会洗耳恭听。
To build Biztalk 2009 projects as part of a TFS 2010 team build I am using a MSBuild exec task to shell out to VS2008 devenv.exe like so...
<Exec Command=""$(BuildMachineLoc)devenv.exe" "$(BiztalkSolutionPath)" /Build "$(BuildFlavor)" /out "$(DropLocation)\$(BuildNumber)\CoreBiztalkBuildOutputLog.txt""/>
This works properly around 95% of the time. Randomly, however, the build will fail with the following error in the log. (I edited this slightly to omit the names of the services I am building)
Build FAILED.
MSB3073: The command ""C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "[path to my solution]" /Build "Release" /out "[path to my drop location]\CoreBiztalkBuildOutputLog.txt"" exited with code -2146233082.
If you check the CoreBiztalkBuildOutputLog.txt file it shows that everything builds succesfully. If you compare this log for a failed build to a build which succeeds they are identical.
Code -2146233082 is not very descriptive... so I found the actual exception from the event viewer on the build machine.
Event Type: Error
Event Source: .NET Runtime
Event Category: None
Event ID: 1023
Date: 2/17/2012
Time: 2:58:41 AM
User: N/A
Computer: XXXXXXXX
Description:
.NET Runtime version 2.0.50727.3625 - Fatal Execution Engine Error (7A0BC59E) (80131506)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
A little poking around on the net indicates that this is a CLR error of some kind. Suggested solutions are to reinstall\repair the .NET framework. That seemed to make sense as the build machine I was using previously was a 7 year old dinosaur which has had various issues for as long as I've owned it. (~2 years)
I ended up provisioning a new VM to run my Biztalk 2009 builds so I could retire that old, physical server completely. Much to my chagrin, however, I am finding that I encounter this same random CLR error on the new server around 5% of the time.
Based on this I am guessing is that this is some sort of defect in the .NET framework which I won't be able to fix. But if anyone has any ideas I am all ears.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您想尝试 MSBuild 任务,这里是您的示例中翻译后的任务:
因为从您的示例中不清楚
$(BuildFlavor)
是否确定Configuration
或Architecture
属性,您可能需要根据您的需要更改它。OutputPath
将在项目级别设置 - 我个人使用 MSBuild 任务输出任务参数来获取构建的程序集。部署到 BizTalk 时(使用 BTSTask),您可以让它复制您的 BizTalk程序集到您想要的目录,并且不必在构建任务中关心它。正如 Bryan 建议的那样,可能值得看一下 BizTalk 部署框架,但很明显,丢弃其他正在运行的框架解决方案不适合您。
If you want to give the MSBuild task a try, here's the translated task from your example:
Since it's not clear from your example whether
$(BuildFlavor)
determines theConfiguration
or theArchitecture
property you may have to change this according to your needs.The
OutputPath
would be set at project level - I personally use the MSBuild task Output Taskparameter to grab the assemblies built. When deploying to BizTalk (using BTSTask) you can have it copy your BizTalk assembly to your desired directory and wouldn't have to care about it in your build task.As Bryan suggests it might be worth to take a look at BizTalk Deployment Framework but it's clear that throwing away an otherwise running solution is not an option for you.