System.TypeLoadException引用.NET 1.0组件后，.NET 4.0迁移 [英] System.TypeLoadException referencing .NET 1.0 assemblies after .NET 4.0 migration
问题描述
还有这是移植自.NET 3.5到.NET 4.0的项目。该项目具有一定的参考.NET 1.0组件，这是围绕COM对象的包装。这些.NET 1.0组件和COM对象是外部公司的产品。该项目编译，但在运行时的第一个点，当软件引用的那些1.0组件定义的对象抛出一个异常：
There's a project which was migrated from .NET 3.5 to .NET 4.0. The project has some references to .NET 1.0 assemblies, which are wrappers around COM objects. These .NET 1.0 assemblies and COM objects are product of an external company. The project compiles, but during runtime the first point when the software references an object defined in those 1.0 assemblies throws an exception:
System.TypeLoadException：未能从程序集加载结构ESRI.MapObjects2.Core.ShapeTypeConstants'ESRI.MapObjects2.Core，版本= 2.4.1.0，文化=中性公钥= 8fc3cc631e44ad86'
结构被标记为资格类型等价，但它有一个静态的或者非公开领域。实际的结构是一个枚举，在反射它看起来是这样的：
The structure is marked as eligible for type equivalence, but it has a static or non-public field. The actual "structure" is an enum, in Reflector it looks like this:
[的Guid（B027CAB1-6908-11D2-AF98-006097DA3688）]
公共枚举ShapeTypeConstants
{
moShapeTypeEllipse = 0x1A的，
moShapeTypeLine =为0x16，
moShapeTypeMultipoint =为0x18，
moShapeTypePoint = 0x15，
moShapeTypePolygon = 0x17已，
moShapeTypeRectangle =的0x19
}
[Guid("B027CAB1-6908-11D2-AF98-006097DA3688")]
public enum ShapeTypeConstants
{
moShapeTypeEllipse = 0x1a,
moShapeTypeLine = 0x16,
moShapeTypeMultipoint = 0x18,
moShapeTypePoint = 0x15,
moShapeTypePolygon = 0x17,
moShapeTypeRectangle = 0x19
}
内部异常为空。我能看到的0x80131522（-2146233054）一个HRESULT，这意味着COR_E_TYPELOAD。我不认为我有任何遗漏机DLL或组件，因为我们的.NET工作正常（它使用相同的code，同样的参考文献）。
The inner Exception is null. I can see a HRESULT of 0x80131522 (-2146233054), it means COR_E_TYPELOAD. I don't think I have any missing native dlls or assemblies, because our .NET works fine (and it uses the same code, same references).
如何解决这一例外？有没有一种简单的方法就像在DLL的配置文件或requiredTargetFramework中的csproj参考部分指定requiredRuntime？
How to fix this exception? Is there an easy way like specifying requiredRuntime in dll's config files or requiredTargetFramework in csproj's Reference section?
推荐答案
如果情节粗糙，那么我可以发挥粗糙了。
If the circumstances are rough, then I can play rough too.
如果我们来看看实际的错误信息，它在抱怨中的结构是静态的或者非公开字段。所谓结构实际上是一个枚举。看似COM层上的包装枚举。还有更多的几十个不同的包装枚举，明确规定每个值。每个枚举还包含一个私人int变量命名为value__。更具体地说，它看起来是这样的：
点域私人specialname rtspecialname INT32值__
If we take a look at the actual error message, it's complaining about a "static or non-public" field in the "structure". The so called structure is actually an enum. Seemingly a wrapper enum on the COM layer. There are more dozens of various wrapper enums, each value is specified explicitly. Each of the enums also contain one private int variable named "value__". More specifically it looks like this:
.field private specialname rtspecialname int32 value__
那么，为什么我们不只是简单地让他们公开：
So why don't we just simply make them public:
- 在拆卸与ILDASM源。
- 在公共替换私人范围限定词。（如果我没记错吧：49位被替换）
- 在最后，我用的修饰的IL ILASM编译的DLL。
和瞧！结果DLL（ESRI.MapObjects2.Core.dll）是311.296字节，而原来是323.584字节长，这让我有点怀疑仍在。但是，如果我覆盖在GAC原始的dll文件和我的修改之一，工作的事情，我们的软件不炸掉了。我无法证实这一切100％的作品，因为我真的不知道我们的软件的GIS一部分。但我设法迄今确定。 什么可以让一些人担心：如果公共变量presence会改变任何结构布局，这样可能会导致枚举值的转变，或其他查询股价。但希望它不会混淆了什么。这是一个快速的黑客攻击，并在生产中它会要求ESRI.MapObjects2.Core.dll在GAC的MapObjects42安装后覆盖。叹。 所以，我并不一定就劝任何人，但它似乎工作，它给了我一些满意，某种复仇的感觉。黑客给了我一个小小的幸福在这一天结束。
And voila! The resulting dll (ESRI.MapObjects2.Core.dll) is 311.296 bytes, while the original is 323.584 bytes long, which makes me a little suspicious still. But if I overwrite the original dll in the GAC with my modified one, things work, our software doesn't blow up any more. I cannot confirm that everything 100% works, because I don't really know the GIS part of our software. But what I managed to get so far is OK. What can make someone worry: if the presence of the public variable would change any structure layout, it might cause the shift of the enum values, or other mixup. But hopefully it won't mix up anything. This is a quick hack, and in production it'd require the overwrite of the ESRI.MapObjects2.Core.dll in GAC after the MapObjects42 installation. Sigh. So I don't necessarily advise it to anyone, but it seems to work, and it gave me some satisfaction, some kind of revenge feeling. Hacking gave me a little happiness at the end of the day.
这篇关于System.TypeLoadException引用.NET 1.0组件后，.NET 4.0迁移的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
