BizTalk Server 项目版本控制
使用 .NET Framework 进行开发时,版本控制受一组标准规则的约束,这些规则可最大程度地减少版本号更改的影响。 根据 .NET Framework 应用程序或组件的部署方式,可以通过应用程序配置文件、XCOPY 安装或其他.NET Framework部署机制来处理依赖项。 如以下部分所示,BizTalk Server增加了版本控制与依赖项的复杂性。
更改版本号的隐患
在.NET Framework开发中,通常会在生成时将程序集版本号更新为当前内部版本号。 但在开发 BizTalk 解决方案时,更改程序集版本号会中断程序集与通过其程序集版本号引用 DLL 的依赖项之间的关系。 下表列出了引用BizTalk Server程序集的项,这些项使用程序集的版本号和更改程序集版本号的效果。
实体 | 更改程序集版本号的影响 |
---|---|
绑定文件 | 更改程序集版本号会导致引用该程序集的所有现有绑定文件失败。 这是因为绑定文件通过包括版本号在内的属性来引用程序集。 可以使用记事本或其他编辑器更新绑定文件中的版本信息。 还可以重新部署解决方案,然后使用 BizTalk Server 管理控制台重新生成绑定文件。 最后,可以使用脚本来进行自动化部署和版本控制。 有关部署的详细信息,请参阅 部署和管理 BizTalk 应用程序。 |
BAM 跟踪配置文件定义 (.btt) 文件 | 更改程序集版本号会导致所有现有 BAM 跟踪配置文件定义文件失败。 BAM 跟踪文件采用二进制文件格式,因此不能进行编辑,而只能重新生成。 如果需要 BAM 跟踪文件,则可能需要执行以下任一操作: - 避免在生成过程中频繁更新版本号。 - 延迟生成 BAM 跟踪配置文件,直到版本号稳定。 |
通过使用 Web Services 发布向导发布的 Web Services | 使用 Web 服务发布向导生成 ASP.NET Web 接口时,BizTalk Server程序集的程序集版本包含在 ASP.NET 源代码中。 程序集版本号在运行时由 ASP.NET 接口用作 Web 服务操作的 bodyTypeAssemblyQualifiedName 属性的一部分。 如果BizTalk Server程序集的版本号更改而不更新 bodyTypeAssemblyQualifiedName 属性,则后续的 Web 服务操作将被BizTalk Server拒绝。 如果接收位置使用 XmlDefaultPipeline,则订阅依赖于文档类型。 订阅使用嵌入的程序集信息,并会在程序集不存在时失败。 如果使用 PassThruPipeline(公开某一端口并让向导创建接收位置时的默认值),则订阅会忽略此嵌入的程序集信息。 |
若要了解有关BizTalk Server程序集和部署的详细信息,请参阅 BizTalk 程序集。
版本控制方法
在规划项目时,可以在以下方法中进行选择:
为给定的可交付结果选择一个固定的程序集版本,并只以增量方式更改文件的版本号
在开发过程中同时以增量方式更改程序集版本和文件版本
下表对这两种方法进行了比较。
固定的程序集版本,动态的文件版本 | 动态的程序集版本,固定或动态的文件版本 |
---|---|
程序集版本号 = 固定版本号 文件版本号 = 内部版本号 |
程序集版本号 = 内部版本号 文件版本号 = 内部版本号 |
如果安装了多个程序集,BizTalk Server运行时可能会选取错误的程序集版本。 | BizTalk Server始终运行最新版本的程序集,即使安装了多个程序集。 |
在任何时候只能部署解决方案的一个版本。 | 可以并列部署解决方案的不同版本(尽管解决方案的其他特征(如架构定义)可能会发生冲突)。 |
需要重新启动 BizTalk 主机以强制加载已更新的程序集。 | 强制BizTalk Server加载新程序集。 |
由于无需编辑引用程序集版本号的文件(例如绑定文件和跟踪配置文件),因此进行新部署的工作量较轻。 | 由于需要不断地使用新版本来更新引用程序集版本号的文件,因此部署的工作量较重。 |
在设计系统原型或开发任何其他非交付项目时,可以选择使用固定程序集版本和动态文件版本方法。 如果不打算将应用程序交付给最终用户,则可以通过固定程序集版本和以增量形式更改文件版本号的方法来简化部署并减少中断的依存关系。 对于版本跟踪,必须记住为每个内部版本以增量形式更改文件版本号。
如果要生成交付给最终用户的项目,则应考虑以增量方式更改程序集版本号,也可以存储一个有意义的文件版本号。 虽然此方法需要进行更多的工作来修改内部版本号和相关联的依存关系,但它可以确保使用最新的程序集。 通过使用自动部署脚本,可以减少版本控制的影响。 若要查看部署示例,请参阅应用程序部署 (BizTalk Server 示例文件夹) 。
注意
应该选择可以确保交付正确文件且简化维护和增强功能的版本控制机制。
映射功能版本编号
可以使用 Scripting functoid 从映射中调用 .NET 程序集。 这样做非常灵活,并可以使开发者能够解决很多不同的自定义映射问题。 它还对映射施加唯一约束 ,它不仅必须在内部引用程序集类型名称,还必须引用所调用的完整程序集版本号。 因此,如果更改了映射所调用的程序集版本号,则所有引用该程序集的链接都将中断。
为了避免这种情况,建议在需要从映射调用程序集时,创建一个只包含映射功能的特定程序集,并且让该程序集的程序集版本号固定不变。 这样,其他帮助器函数可以更新程序集的版本,而不会中断映射。
如果映射开发完成后更改了通过该映射引用的某个程序集,则应考虑在映射编辑器外更新该映射文件,使之反映已更新的版本号。
使用记事本修改映射文件以反映更新的版本号
使用“ 开始 ”菜单启动记事本。
在记事本的“ 文件 ”菜单上,单击“ 打开”。 在“ 打开 ”对话框中,选择要修改的映射文件,然后单击“ 打开”。
在 “编辑” 菜单中,单击 “查找” 。 在“ 查找 ”对话框中,输入 Assembly=,然后单击“ 查找下一个”。
如果存在对外部程序集的脚本引用,则记事本应该找到一个类似如下所示的 XML 元素:
<Script Language="ExternalAssembly" Assembly="Contoso.Scripts, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5145e4e089" Class="Contoso.Scripts" Function="CalculateValue" AssemblyPath="Contoso.Scripts.dll"/>
更新版本号。 如果有多个实例,请在“编辑”菜单上使用“替换”。
保存文件。
现在即可以用映射编辑器打开该映射。
另请参阅
部署 BizTalk 应用程序的最佳做法
Admin(BizTalk Server 示例文件夹)
以编程方式部署和启动业务流程的新版本
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈