简体   繁体   English

从TFS2010迁移到TFS2012时,System.Drawing V4的FileNotFoundException。 异常代码0xE0434F4D

[英]FileNotFoundException for System.Drawing V4 when migrating from TFS2010 to TFS2012. Exception Code 0xE0434F4D

I have a large solution developed in VS2005 .Net 2. We migrated from TFS2010 to TFS2012 (keeping the Framework as .Net v2). 我有一个在VS2005 .Net 2中开发的大型解决方案。我们从TFS2010迁移到TFS2012(将框架保持为.Net v2)。 All work fine in IDE, build and install, but when program is executed, get the following Problem signature: 所有这些都可以在IDE中正常工作,构建和安装,但是在执行程序时,请获得以下问题签名:

Problem Event Name: CLR20r3
Problem Signature 01: myProgram.exe
Problem Signature 02: 1.0.0.5
Problem Signature 03: 550f8264
Problem Signature 04: mscorlib
Problem Signature 05: 2.0.0.0
Problem Signature 06: 53a12268
Problem Signature 07: f15
Problem Signature 08: 3
Problem Signature 09: System.IO.FileNotFoundException
OS Version:      6.1.7601.2.1.0.256.48
Locale ID:           2057

TFS2010 build server is Windows XP SP3 x86. TFS2010构建服务器是Windows XP SP3 x86。

TFS2012 build server is Windows Server 2008 R2 x64. TFS2012构建服务器是Windows Server 2008 R2 x64。

I have migrated the Framework to .Net 4 and all works fine, but unfortunately some clients requite .Net 2. 我已将框架迁移到.Net 4,并且一切正常,但不幸的是,某些客户端退出了.Net 2。

  1. Using WinDbg gave me the following: 使用WinDbg给了我以下内容:

     Problem Signature 04 gives us where the error originated, mscorlib. Problem Signature 07 gives us the methodDef, which we can use to get the methodDesc “702b8c10” => “System.RuntimeTypeHandle.GetTypeByName(String.String, Boolean, Boolean, Boolean, System.Threading.StackCrawlMark ByRef)” Problem Signature 08 gives us the Offset so when I do a dump of the IL, I get “ldarg.0” at offset 3. 

As far as I can see, argument 1 of System.RuntimeTypeHandle.GetTypeByName ie the string is 0, hence the FileNotFound exception, but it doesn't tell me the file name. 据我所知,System.RuntimeTypeHandle.GetTypeByName的参数1即字符串为0,因此FileNotFound异常,但它没有告诉我文件名。

  1. Using FusionLog gave me the following: 使用FusionLog为我提供了以下内容:

It successfully loads System.Drawing v2 but then also tries to load v4 which fails (I have checked that none of the projects reference any .Net v4 assemblies). 它成功加载了System.Drawing v2,但随后又尝试加载了失败的v4(我已经检查过,没有项目引用任何.Net v4程序集)。

** Assembly Binder Log Entry  (30/03/2015 @ 14:45:05) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  C:\Program Files\Common Files\myProgram\myProgram.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = HOST1\Administrator
LOG: DisplayName = System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///C:/Program Files/Common Files/myProgram/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = myProgram.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Program Files/Common Files/myProgram/System.Drawing.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Common Files/myProgram/System.Drawing/System.Drawing.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Common Files/myProgram/System.Drawing.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/Common Files/myProgram/System.Drawing/System.Drawing.EXE.
LOG: All probing URLs attempted and failed.

Here's an excerpt from Procmon: 这是Procmon的摘录:

CreateFile  C:\Windows\assembly\GAC_32\myProgram.resources\1.0.0.5_en_0a4a2ad97614f98d  PATH NOT FOUND
CreateFile  C:\Windows\assembly\GAC_MSIL\myProgram.resources\1.0.0.5_en_0a4a2ad97614f98d    PATH NOT FOUND
CreateFile  C:\Windows\assembly\GAC\myProgram.resources\1.0.0.5_en_0a4a2ad97614f98d PATH NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\en\myProgram.resources.dll  PATH NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\en\myProgram.resources\myProgram.resources.dll  PATH NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\en\myProgram.resources.exe  PATH NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\en\myProgram.resources\myProgram.resources.exe  PATH NOT FOUND
CreateFile  C:\Windows\assembly\GAC_32\System.Drawing\4.0.0.0__b03f5f7f11d50a3a PATH NOT FOUND
CreateFile  C:\Windows\assembly\GAC_MSIL\System.Drawing\4.0.0.0__b03f5f7f11d50a3a   NAME NOT FOUND
CreateFile  C:\Windows\assembly\GAC\System.Drawing\4.0.0.0__b03f5f7f11d50a3a    PATH NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\System.Drawing.dll  NAME NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\System.Drawing\System.Drawing.dll   PATH NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\System.Drawing.exe  NAME NOT FOUND
CreateFile  C:\Program Files\Common Files\myProgram\System.Drawing\System.Drawing.exe   PATH NOT FOUND

As you can see it tries to load myProgram.resources.dll and fails, then tries to load Framework v4 files, which made me look at the resource files. 如您所见,它尝试加载myProgram.resources.dll并失败,然后尝试加载Framework v4文件,这使我着眼于资源文件。

  1. mscorlib.resources.dll is installed by language packs of .Net and by Silverlight. mscorlib.resources.dll由.Net语言包和Silverlight安装。 Tried installing Silverlight as our TFS2010 build server had this, but didn't work. 尝试安装Silverlight,因为我们的TFS2010构建服务器具有此功能,但是没有用。

  2. [This article]: "Could not load file or assembly System.Drawing or one of its dependencies" error on .Net 2.0, VS2010 and Windows 8 says the System.Drawing error is due to a resource file bug in VS. [本文] : . Net 2.0,VS2010和Windows 8上出现“无法加载文件或程序集System.Drawing或其依赖项之一”错误,该System.Drawing错误是由于VS中的资源文件错误引起的。 I have tried the suggested solution: 我尝试了建议的解决方案:

Edit the top line of the Image stream: AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w TO AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w None of the resource files in my solution has the erroneous top line in the image stream "j00LjAuMC4w" 编辑图像流的顶线:AAEAAAD ///// AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w TO AAEAAAD在我的解决方案资源文件的///// AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w概无于图像流“j00LjAuMC4w”错误的顶线

Also checked all the .resx files for 4.0.0.0 version but they were all 2.0.0.0 还检查了所有.resx文件的4.0.0.0版本,但它们都是2.0.0.0

  1. Here's the Crash Mini Dump: 这是崩溃迷你转储:

Dump Summary 转储摘要

Dump File:  WER6229.tmp.mdmp :     C:\Users\Administrator\AppData\Local\Temp\WER6229.tmp.mdmp
Last Write Time:    16/04/2015 10:46:17
Process Name:   myProgram.exe : C:\Program Files (x86)\Common Files\myProgram\myProgram.exe
Process Architecture:   x86
Exception Code: 0xE0434F4D
Exception Information:  An exception came from the CLR
Heap Information:   Not Present

System Information
------------------
OS Version: 6.1.7601
CLR Version(s): 2.0.50727.5485

Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
myProgram.exe   C:\Program Files (x86)\Common Files\myProgram\myProgram.exe 1.4.2015.12
ntdll.dll   C:\Windows\SysWOW64\ntdll.dll   6.1.7601.18247
mscoree.dll C:\Windows\System32\mscoree.dll 4.0.40305.0
kernel32.dll    C:\Windows\SysWOW64\kernel32.dll    6.1.7601.18409
KERNELBASE.dll  C:\Windows\SysWOW64\KERNELBASE.dll  6.1.7601.18409
advapi32.dll    C:\Windows\SysWOW64\advapi32.dll    6.1.7601.18247
msvcrt.dll  C:\Windows\SysWOW64\msvcrt.dll  7.0.7601.17744
sechost.dll C:\Windows\SysWOW64\sechost.dll 6.1.7600.16385
rpcrt4.dll  C:\Windows\SysWOW64\rpcrt4.dll  6.1.7601.18532
sspicli.dll C:\Windows\SysWOW64\sspicli.dll 6.1.7601.18719
CRYPTBASE.dll   C:\Windows\SysWOW64\CRYPTBASE.dll   6.1.7600.16385
mscoreei.dll    C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll  4.0.30319.18408
shlwapi.dll C:\Windows\SysWOW64\shlwapi.dll 6.1.7601.17514
gdi32.dll   C:\Windows\SysWOW64\gdi32.dll   6.1.7601.18577
user32.dll  C:\Windows\SysWOW64\user32.dll  6.1.7601.17514
lpk.dll C:\Windows\SysWOW64\lpk.dll 6.1.7601.18177
usp10.dll   C:\Windows\SysWOW64\usp10.dll   1.626.7601.18454
imm32.dll   C:\Windows\System32\imm32.dll   6.1.7601.17514
msctf.dll   C:\Windows\SysWOW64\msctf.dll   6.1.7600.16385
mscorwks.dll    C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll  2.0.50727.5485
msvcr80.dll C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6229_none_d089f796442de10e\msvcr80.dll  8.0.50727.6229
shell32.dll C:\Windows\SysWOW64\shell32.dll 6.1.7601.18429
ole32.dll   C:\Windows\SysWOW64\ole32.dll   6.1.7601.17514
profapi.dll C:\Windows\SysWOW64\profapi.dll 6.1.7600.16385
mscorlib.ni.dll C:\Windows\assembly\NativeImages_v2.0.50727_32\mscorlib\38bf604432e1a30c954b2ee40d6a2d1c\mscorlib.ni.dll    2.0.50727.5485
mscorsec.dll    C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorsec.dll  2.0.50727.5483
wintrust.dll    C:\Windows\SysWOW64\wintrust.dll    6.1.7601.18205
crypt32.dll C:\Windows\SysWOW64\crypt32.dll 6.1.7601.18277
msasn1.dll  C:\Windows\SysWOW64\msasn1.dll  6.1.7601.17514
comctl32.dll    C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18201_none_ec80f00e8593ece5\comctl32.dll 5.82.7601.18201
cryptsp.dll C:\Windows\System32\cryptsp.dll 6.1.7600.16385
rsaenh.dll  C:\Windows\System32\rsaenh.dll  6.1.7600.16385
imagehlp.dll    C:\Windows\SysWOW64\imagehlp.dll    6.1.7601.18288
ncrypt.dll  C:\Windows\System32\ncrypt.dll  6.1.7601.18714
bcrypt.dll  C:\Windows\System32\bcrypt.dll  6.1.7600.16385
bcryptprimitives.dll    C:\Windows\SysWOW64\bcryptprimitives.dll    6.1.7600.16385
userenv.dll C:\Windows\SysWOW64\userenv.dll 6.1.7601.17514
gpapi.dll   C:\Windows\System32\gpapi.dll   6.1.7601.18711
cryptnet.dll    C:\Windows\System32\cryptnet.dll    6.1.7601.18205
Wldap32.dll C:\Windows\SysWOW64\Wldap32.dll 6.1.7601.17514
SensApi.dll C:\Windows\System32\SensApi.dll 6.1.7600.16385
uxtheme.dll C:\Windows\System32\uxtheme.dll 6.1.7600.16385
mscorjit.dll    C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll  2.0.50727.5467
myProgram.Engine.dll    C:\Windows\assembly\GAC_MSIL\myProgram.Engine\1.0.0.5__0a4a2ad97614f98d\myProgram.Engine.dll    1.4.2015.12
System.ni.dll   C:\Windows\assembly\NativeImages_v2.0.50727_32\System\908ba9e296e92b4e14bdc2437edac603\System.ni.dll    2.0.50727.5485
System.Drawing.ni.dll   C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Drawing\836e10dfd0811b303553216f5cb092ef\System.Drawing.ni.dll    2.0.50727.5483
System.Windows.Forms.ni.dll C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\1453d9e9a4989833ef3db4b22549ba1a\System.Windows.Forms.ni.dll    2.0.50727.5483
myProgram.Designer.dll  C:\Windows\assembly\GAC_MSIL\myProgram.Designer\1.0.0.5__0a4a2ad97614f98d\myProgram.Designer.dll    1.4.2015.12
myProgram.UI.dll    C:\Windows\assembly\GAC_MSIL\myProgram.UI\1.0.0.5__0a4a2ad97614f98d\myProgram.UI.dll    1.4.2015.12
DevComponents.DotNetBar.dll C:\Windows\assembly\GAC\DevComponents.DotNetBar\5.8.0.0__7eb7c3a35b91de04\DevComponents.DotNetBar.dll   5.8.0.0
version.dll C:\Windows\System32\version.dll 6.1.7600.16385
apphelp.dll C:\Windows\System32\apphelp.dll 6.1.7601.17514

The Mini Crash Dump gave me the Exception Code 0xE0434F4D. 迷你故障转储给了我异常代码0xE0434F4D。

  • Tried [this idea] [program name].exe has stopped working running myProgram as admin but no help. 尝试过[此主意] [程序名称] .exe已停止以管理员身份运行myProgram的工作 ,但没有帮助。
  • [This blog] http://blog.toxa.de/archives/38 (also dealing with .Net 2) gave me the idea remove the icon from the SplashScreen. [此博客] http://blog.toxa.de/archives/38 (也处理.Net 2)使我想到从SplashScreen中删除图标。 Which affects the error raised. 这会影响所引发的错误。 Instead of getting the 1 error as described above you get 3 errors with the continue option. 而不是如上所述获得1错误,而是使用Continue选项得到3错误。

    1. From the build log: 从构建日志中:

I saw MSBuild from Framework v4 was used 我看到使用了Framework v4的MSBuild

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /nologo /noconsolelogger "F:\Builds\59\Platform\myProject_BugFixing_CI\BuildType\TFSBuild.proj" /m:1 /nr:False "@F:\Builds\59\Platform\myProject_BugFixing_CI\BuildType\TfsBuild.rsp"
  • Have tried adding Set ToolsVersion = 2.0 and TargetFrameworkVersion = v2.0 in each of the project files and ToolsVersion="2.0" in TFSBuild.proj. 尝试在每个项目文件中添加Set ToolsVersion = 2.0和TargetFrameworkVersion = v2.0,并在TFSBuild.proj中添加ToolsVersion =“ 2.0”。

  • Ran Framework v2 MSBuild from command line: 从命令行运行Ran Framework v2 MSBuild:

    • None of the switches (/m:1 /nr:False "@F:\\Builds\\59\\Platform\\myProgram_BugFixing_CI\\BuildType\\TfsBuild.rsp") are recognised. 没有任何开关(/ m:1 / nr:False“ @F:\\ Builds \\ 59 \\ Platform \\ myProgram_BugFixing_CI \\ BuildType \\ TfsBuild.rsp”)被识别。
    • After removing these, build fails on Line 7 of TFSBuild.proj, as SolutionRoot is not recognised. 删除这些文件后,由于无法识别SolutionRoot,因此在TFSBuild.proj的第7行上构建失败。
    • If I hard code this, the build fails on C:\\Program Files (x86)\\MSBuild\\Microsoft\\VisualStudio\\TeamBuild\\ Microsoft.TeamFoundation.Build.targets Line 359 also referring to SolutionRoot. 如果我对此进行硬编码,则在C:\\ Program Files(x86)\\ MSBuild \\ Microsoft \\ VisualStudio \\ TeamBuild \\ Microsoft.TeamFoundation.Build.targets第359行上的构建也会失败,该行也引用SolutionRoot。 It says there is an invalid child element _SolutionRoot in the namespace. 它说名称空间中有一个无效的子元素_SolutionRoot。
    • This suggests to me that MSBuild v4 is the correct version and must also be used by TFS2010 build server. 这向我表明MSBuild v4是正确的版本,TFS2010构建服务器也必须使用它。

      1. TFS Build.log revealed different ResGen versions used in build: TFS Build.log显示了构建中使用的不同ResGen版本:

I replaced the TFS2012 build server ResGen with the TFS2010 build server exe and ran a build successfully, that made no difference. 我用TFS2010构建服务器exe替换了TFS2012构建服务器ResGen并成功运行了构建,这没有什么区别。

    TFS2010 – Path of ResGen used: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\ResGen.exe
    This is v3.5.30729.4507 and dated 19/03/2010

    TFS2012 – Path of ResGen used: C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\bin\Resgen.exe
    This is v2.0.50727.42 and dated 23/09/2005

[This post] MSBuild cant find resgen.exe suggests setting [本文] MSBuild无法找到resgen.exe建议设置

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\CurrentVersion

to the same value as the setting ProductionVersion in 与设置中的ProductionVersion相同的值

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A

it was v8, but this didn't work. 那是v8,但这没用。

  1. Using IlSpy on myProgram.exe (both versions) to decompile the code show two tree structures in which the decompiled .cs files are identical but the binary .resource files are different (both size & content). 在myProgram.exe(两个版本)上使用IlSpy进行反编译代码显示了两个树结构,其中反编译的.cs文件相同,但是二进制.resource文件不同(大小和内容)。

In particular binary editing reveals that at the tail of mainform.resources are the lines (there are of course other diffs): 特别是二进制编辑揭示了mainform.resources的末尾是行(当然还有其他差异):

System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d

in the old TFS2010 exe, vs 在旧的TFS2010 exe中,

System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

in the new TFS2012 exe. 在新的TFS2012 exe中。 This means that the new build is using .Net 4 binary serialisation; 这意味着新版本使用的是.Net 4二进制序列化。 the old is using .Net 2 binary serialisation. 旧版本使用.Net 2二进制序列化。

A quick decompile of ResGen shows it's a pretty simple program that: 快速反编译ResGen可以看到它是一个非常简单的程序,它可以:

  • Parses args 解析参数
  • Reads resources from .resx files 从.resx文件读取资源
  • Uses a binary resource writer to write the output file 使用二进制资源编写器写入输出文件

I suspect that the two versions are pretty similar since there should be no real need to change (both are actually flagged as .net2/AnyCPU). 我怀疑这两个版本非常相似,因为实际上没有必要进行更改(实际上都标记为.net2 / AnyCPU)。

What's more interesting is that the binary serialiser used comes from mscorlib therefore the new build must be using the .Net 4 mscorlib (but the build log says it's v2 更有趣的是,所使用的二进制序列化程序来自mscorlib,因此新版本必须使用.Net 4 mscorlib(但该版本日志表示它是v2

C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
FusionName = mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

) despite the fact that ResGen is actually a .Net 2 binary – this would explain why overwriting the the ResGen.exe version tried in point 7 above had no effect. ),尽管ResGen实际上是.Net 2二进制文件–这可以解释为什么覆盖上面第7点中尝试的ResGen.exe版本无效。

通过从以下位置更改TFS2012构建服务器来解决:Windows Server 2008 R2 x64 => Windows 7 x86

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM