Windows 工作流类型加载异常
我正在使用 Windows 工作流程构建一个状态机，并且尝试从解决方案中的另一个程序集中新建一个对象。 当我构建解决方案时，我从 StateActivityValidator 收到 TypeLoadException（它在成功构建后运行以查看所有必需的属性是否已设置等）。
我尝试创建实例的类型非常简单，它有一个默认的公共构造函数，并且两个程序集都经过签名。 有什么想法可能是什么问题吗？
I am building a state machine with windows workflow, and I am trying to new up an object from another assembly in my solution. When I build the solution, I get a TypeLoadException from the StateActivityValidator (which runs after a successful build to see that all the required properties are set and such).
The type I am trying to create an instance of is very simple, it has a default public constructor, and both assemblies are signed. Any ideas what the problem could be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
此问题是由于 GAC 中这些程序集的版本不匹配造成的。
This problem was caused by having mismatched versions of these assemblies in the GAC.
我的猜测是，在 WF 尝试反序列化之前，其他程序集尚未加载。 您可以通过在应用程序开始执行之前简单地新建一个此类实例来测试这一点（即，在 Program 类的 Main 方法中，对于 winforms 应用程序）。
如果是这种情况，您可以尝试一些方法。
首先，在反序列化之前强制加载内存中所需的所有程序集（如上面的测试）。 这个方法，恕我直言，很糟糕。
第二，您可以添加逻辑运行时类型解析。 这似乎是可能的，但我从未这样做过。
第三，修改序列化工作流程，为其提供加载类型所需的信息。
我不确定您如何序列化您的工作流程，因此我无法确切地告诉您如何执行此操作。 我可以告诉你，工作流程被序列化为 xaml。 XamlReader 可以在反序列化时加载 xaml 中包含的类型的程序集。 这是通过使用特殊类型的 XML 命名空间来完成的。
假设这是您缺少的类型（在序列化工作流程中）：
并且在程序集 MyCode.DLL 中定义了 MyType：
则该类型的命名空间将为：
clr-namespace:MyCodeNamespace; assembly=MyCode它在序列化工作流程中将显示为：
XamlReader 识别该命名空间，确定程序集名为 MyCode.DLL 或 MyCode.EXE，查找它，将其加载到内存中，然后查找 MyCodeNamespace.MyType。
那么问题就变成了，“我如何让我的工作流程序列化该命名空间？？？” 答案是“我不知道”。 也许您可以使用以下程序集属性：
但我不确定工作流序列化程序是否会尊重这些属性。 天啊，我什至不确定工作流序列化器是否会首先尊重 clr 命名空间。 您可以尝试一下，如果没有的话，可以在此基础上提出另一个问题。
My guess is that this other assembly isn't loaded before WF is trying to deserialize. You can test this by simply new-ing up an instance of this type before your application starts executing (i.e., in the Main method of your Program class, for a winforms app).
If this is a case, you can try a few things.
First, force loading of all assemblies you need in memory before deserialization (like the test above). This method, imho, sucks.
Second, you can add logic to runtime type resolution. It appears to be possible, but I've never done it.
Third, modify your serialized workflow to give it the information you need to load the type.
I'm not sure how you are serializing your workflow, so I can't tell you exactly how to do this. I can tell you that workflows are serialized to xaml. The XamlReader can, on deserialization, load assemblies of types included in the xaml. This is done by using a special type of XML namespace.
Let's say this is your missing type (in a serialized workflow):
and MyType is defined, in the assembly MyCode.DLL:
then the namespace for this type would be:
clr-namespace:MyCodeNamespace;assembly=MyCodeand it would appear in your serialized workflow as:
The XamlReader recognizes that namespace, determines the assembly is called MyCode.DLL or MyCode.EXE, looks for it, loads it in memory, and looks for MyCodeNamespace.MyType.
The question then becomes, "how do I get my workflow to serialize that namespace???" The answer is "I dunno". Perhaps you can use the following assembly attributes:
but I'm not sure if the Workflow serializer will respect these. Hell, I'm not even sure if the Workflow serializer will respect the clr-namespace in the first place. You can try it out, and if not ask another question on SO based on this.