问题标签 [biztalk-deployment]

我有一个包含两个项目的解决方案 - 一个项目包含我的架构和 BizTalk 编排，另一个项目包含一个从我的编排中引用并执行实际工作的 DLL（它是共享代码，所以我不可能将它合并到BizTalk 程序集）。第二个程序集是作为 BizTalk 的引用添加的，我可以毫无问题地从编排中引用 #2 中的方法。

但是，当我从 VS -> BizTalk 部署时，它不会带上我的资源程序集 - 它只是部署 BizTalk 程序集。如果我尝试触发我的编排，我会收到无法加载引用的程序集的错误，但是一旦我将它添加到 GAC 和我的 BizTalk 应用程序的“资源”列表中，事情就会完美运行。

如何将此程序集标记为必须与我的 BizTalk 程序集一起部署的东西？我只是在某处缺少参考设置吗？

通过 Web 服务调用尝试 BizTalk

请求/响应在我自己的开发机器上运行良好，但不是在测试中......

将 MSI 导出到我的部署测试服务器（一个单独的虚拟服务器），使用 Application/Import 创建应用程序，然后对其进行测试以发现它不起作用...

• 检查事件日志并显示“无法加载文件或程序集”的 XLANG 错误

• 检查 GAC 并且 BizTalk 程序集不存在...

• 所以手动添加它，这似乎可以解决问题

添加的 Web 服务引用是否意味着程序集必须作为部署的一部分进行 GAC？

只是让我感到困惑，尝试部署到真正的测试服务器，导入 MSI，将 DLL 手动复制到 GAC ......它失败并在 eventlog 中出现 XLANG 错误:-(

• 知道这里发生了什么吗？

当我将应用程序部署到我们的 BizTalk 服务器时，我们会部署到测试机器，添加所有必要的资源，然后导出我们在生产服务器上导入的 MSI（我们有两个）。前几天我注意到我们的生产服务器上有几十个文件夹，这些文件夹似乎是每个开发人员源代码位置的副本。

例如：

• C:\开发\MyProject1
• C:\Projects\SomeProject
• C:\Users\Ryan\我的文档\Visual Studio 项目\另一个项目
• 好多其它的

它们都是我们部署到 BizTalk 的项目，并且这些文件夹不包含源代码，只是每个 BizTalk 项目的“部署”文件夹，其中包含 DLL 文件。但是，我认为 MSI 软件包正在将 DLL 文件添加到 GAC，或者至少将它们放在 MSI 安装目标文件夹中（所有 MSI 文件都安装到“C:\Biztalk\ProjectName”）。

有人可以在这里阐明一下吗？这些额外的副本可以安全删除吗？这会阻止我的 BizTalk 应用程序运行吗？

我的 BizTalk 应用程序出了点问题；我无法删除它们，同时无法从 Visual Studio 部署最新版本。我正在使用 BizTalk 2009。

Visual Studio 上显示的错误：

引用的 BizTalk 项目正在被其他进程使用，因此无法更新它

我的主机实例和应用程序处于停止状态。我尝试从 GAC 中删除 dll ，但没有用。

我还在学习 BizTalk 和 EDI。当我最初在现在的公司开始时，我继承了我前任的计算机，所以很多配置已经到位。我最近买了一台新笔记本电脑，并且几乎完成了新开发环境的配置。在我来到这里之前，没有关于如何设置开发环境的文档（我创建了这样一个相当冗长的文档）。

我似乎无法弄清楚的最后一块是 EdiRecieve 和 SendEdi 端口。它们在我的旧开发环境中，但没有出现在我的新环境中。从我能够打开谷歌垃圾箱潜水的情况来看，它们存在于 Microsoft.BizTalk.Edi.EdiPipelines 但默认情况下似乎没有安装。我的问题是如何在我用于开发的主要 BizTalk 应用程序中获得这些？

另一个副业是，有一个显然默认安装的 BizTalk EDI 应用程序，它确实具有我正在寻找的管道。我是否需要以某种方式引用该应用程序或其他东西？

我试过GAC'ing dll，但这似乎没有用。

我目前负责建立多环境 BizTalk 部署，我们计划在 BizTalk 组中部署两个或多个 BizTalk Server 以提供高可用性和可扩展性。

我们现在关心的是如何处理 WCF SQL 和文件适配器等适配器的并发性，因为例如对于 SQL 适配器，两个 BizTalk 接收主机可能会继续轮询同一个数据库表。

最初我对 SQL 的想法是使用锁定提示，但我不确定是否对此有任何其他担忧，或者是否有任何其他经过验证的解决方案。

对于文件适配器我知道可以设置接收适配器以在处理过程中更改文件的文件名，以便其他 BizTalk 主机将避免拾取文件但我不太确定此解决方案是否足以处理并发.

我将不胜感激任何帮助/建议。

非常感谢

我们正在研究为我们的开发团队升级到 Team Foundation Server 2008 的可能性。我们的主要原因之一是围绕 BizTalk 2009 的一些部署功能，但我很好奇 BizTalk 之外的其他项目还有哪些其他好处。

到目前为止，我们的一些兴趣正在转向一键式构建和部署过程、添加单元测试和持续集成。我工作的公司向前迈出了明确的一步。

在向高层管理人员推销此内容时，我还应该查看哪些其他好处或信息？我正在寻找技术原因，金钱不是这个讨论真正关心的问题。

有没有人为 BizTalk 有很多烦人的部署/构建问题而烦恼。

例如，如果我使用 c# 程序集类进行构建/部署，我经常会收到 sgen.exe 错误，如果我将它们从程序集中删除，这些错误会得到修复，但是一些依赖项再次出现问题，这意味着我必须重建它并重新启动 Visual Studio，因为它们不会触发程序集。是的，我总是使用构建事件命令：

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i $(TargetFileName)

我在构建时也遇到了很多关于序列化字符串或布尔值等的问题，在我重新启动我的 Visual Studio 解决方案后，这些问题也得到了解决。

此外，当您要导入 .msi 文件时，您必须取消登记并删除所有正在运行的实例才能正确部署它。

并且不要忘记重新启动您的主机实例，这是您的 Visual Studio 项目的一个选项，但几乎无法正常工作，因此手动重新启动您的主机实例已不仅仅是例行公事。

让我们面对现实吧，还有很多其他的事情也在不断增加，比如参考问题等，我相信在一天的工作之后我还能想到更多。

有人对这些问题有一些技巧吗？因为我每小时都会遇到他们。我只是想知道其他人是否也遇到过这些问题，并且可能解决了其中一些问题。

我在部署一些架构时遇到问题：

我有包含 schemaA 的程序集 A，包含引用程序集 A 的程序集 B 和包含架构 C 并且还引用程序集A 的程序集B。

我可以很好地部署 asssemblyA 并在 BizTalk Admin 的架构中查看 schemaA。

我可以很好地部署 assemblyB 或 assemblyC，并在 BizTalk admin 中查看相应的架构。

如果我在 assemblyB 已部署时尝试部署 assemblyC，则 assemblyB 及其架构将从 BizTalk 管理员中消失（反之亦然）。

如果我从 B 或 C 中删除对 assemblyA 的引用，那么我可以很好地将所有三个部署在一起（但在实际情况下需要该引用）。

我究竟做错了什么？

我们有多个 BizTalk 2006 应用程序服务器，我发现几乎不可能在它们上保持我们项目的版本同步。部署 MSI 包、导入它们、匹配 GAC 中的文件、部署一些注册表更改是一个乏味的过程，如果错过了一个步骤或有人将 DLL 的更新副本直接部署到一台服务器而不是另一台服务器，则没有简单的方法来告诉。

其他人如何确保两台服务器之间的软件副本是相同的版本？

一些背景：

我们的环境有两个（非集群）BizTalk 前端服务器和一个单独的数据库后端。直到最近，虽然我们都配置了两个前端，但由于一些故障排除，主机实例在第二台服务器上停止了。它们已经被禁用了几个月，同时我们部署了一些更新的代码。

今天早上，我在 GAC 上做了一个文件夹 diff，以及保存我们部署项目的 DLL 的本地磁盘副本的文件夹（两台服务器上的 C:\OurProject\），所有内容都匹配 - 相同的文件大小，相同时间戳。但是，一旦我打开第二组服务，很明显 Server2 使用的是旧版本的项目 DLL - 在接下来处理的三个文件中，两个结果正常，一个明显过期。

请帮我避免动脉瘤。