Biztalk中程序集引用在何处序列化或反序列化，以及如何序列化或反序列化

我遇到了一个问题。我有一个BizTalk 2010应用程序，它引用了第三方架构dll。我们的架构师告诉我们不要直接引用它，因为序列化这个大约9MB的大型dll会花费更多的时间，这将导致Biztalk工作更频繁

由于此第三部分dll是一个模式dll，因此在部署任何其他应用程序之前，它将部署到任何应用程序下的MgmtDb。我们的业务流程消息具有从该架构dll引用的消息类型

我想知道的是，这个外部dll的序列化在哪里发生，因为这个dll已经部署，业务流程实例可以根据传入的任何请求消息引用它

是否对创建业务流程实例的每条消息进行序列化

请分享你的想法

---

谢谢。

虽然引用的程序集确实将添加到MgmtDB中，但AFAIK中添加的只是有关程序集及其工件的元数据，例如

use BizTalkMgmtDb
select * from dbo.bts_assembly
... dbo.bts_orchestration
... dbo.bt_DocumentSpec
etc.

他/她可能正在引用从程序集中的架构类创建的消息实例（并存储在messagebox中）。但是消息的大小将由其中数据的大小决定，而不是由程序集的大小决定

由于您似乎需要引用的消息架构，因此除了在新项目中引用它之外，没有太多的选择（例如，除非您有第三方程序集的源，您可以在其中重构它并将其拆分为几个较小的程序集）。需要在BizTalk服务器上部署第三方程序集，并对其进行签名和授权

---

但是，如果此引用的架构程序集还包含其他构件，例如在业务流程中用作变量的自定义类，则在业务流程到达某一点时，也需要立即创建这些类（为了避免这种情况，您需要在脱水之前确定变量的作用域和/或使用原子作用域来防止BizTalk脱水，但这通常是一个坏主意，因为它会限制可伸缩性）

您的架构师对BizTalk何时根据其定义的架构对文档进行验证做出了错误的假设

根据庞大的架构（如EDIFACT或OASIS）验证大型文档可能需要大量资源。因此，BizTalk不会根据其相关架构验证传入文档，除非您在接收管道中明确要求它这样做。默认情况下，大多数管道组件将其“ValidatedDocument”属性设置为o“False”。因此，BizTalk将仅基于命名空间和根节点执行文档识别，这是在流读取文档流的前几百个字节时完成的

因此，您可以自由地“引用”第三方DLL，唯一的性能损失将是在编译和部署时。如果出于某种原因，您需要根据此架构验证文档，则无论如何，您都需要将其放在管理数据库中