During biztalk deploy when it is not requred to import msi via console
哪些BizTalk应用程序，业务流程，架构，地图更改被允许不强制通过管理控制台导入MSI，而仅在GAC中安装DLL？
通过控制台强制导入以停止Ochiestration和终止实例，但在GAC中安装仅需要重新启动此应用程序的主机。因此有时在不停止生产环境中的所有内容时会很方便。
- 请对此进行详细说明，并对问题所在进行更清晰的描述。那是生成的MSI吗？什么样的工具会生成它，它的作用到底是什么？
-
@Stein？smul这是一个普遍的问题，我的目标是不停止应用程序，编排并终止这些应用程序的运行实例
受支持：从不。
您必须始终正确部署BizTalk应用程序。这对BizTalk没什么特别的，所有平台都有不同的部署过程。
在开发过程中：辅助类以及对Schema和Map的内部更改通常可以顺畅引入。什么都不会改变任何工件的签名。编排永远不会错位，因为跟踪使用该结构，并且即使进行内部更新也可能会微妙地更改。
-
当您说它从未被支持时，您的意思是MS不支持它。您是否有MS提供的任何支持文档/链接
-
不支持它，因为它不是Microsoft的经过测试的过程。这并不意味着它就行不通，只是它不是产品开发和测试的正确程序。不过，不是。通过开发可靠的部署过程来解决实际问题。
-
它一直在工作，我们一直在使用它。在消息量很大的大型环境中，无法选择停止和重新部署。
-
@VikasBhardwaj我已经运行了很多高容量的应用程序，并且我们总是正确地做到这一点。不要让便利成为借口。
-
这不是为了方便。如果MS支持，那么我认为这不是问题。还有为什么在不需要时执行额外的部署步骤。
如果仅在生产环境中GAC一个DLL而没有将其导入到BizTalk中，则会有很大的风险。
如果对于下一次部署，您从Prod生成了一个备份MSI，它将包含BizTalk数据库中的旧DLL，而不是GACced版本。这可能意味着，如果您必须使用该MSI进行回滚，则会丢失补丁程序。当另一家公司的某人做了补丁时，我们经历了这种情况，不仅如此，还没有将更改检查到源代码管理中，这就是为什么我们必须首先回滚的原因，因为该更改不在发行包中。
在部署后必须回滚的另一种情况是，您使用以前用于部署的以前的MSI(预补丁程序)而忘记重新应用补丁程序。同样，这将导致您遇到问题。
如果存在问题，并且BizTalk中的架构或映射与GACced版本不匹配，这将使诊断任何问题变得更加困难。
总而言之，不要这样做，而要使用正确的部署程序包，这些程序包是由构建服务器生成的(因此只有源代码管理中的程序最终会被部署)。
-
如果使用开发人员和构建服务器来管理MSI，则无需从BizTalk环境中生成MSI。我认为，从BizTalk导出MSI是不正确的做法。
-
@VikasBhardwaj是的，我同意，使用构建服务器生成构建软件包是最佳实践，然后回滚即可，只需应用上一个即可。但是，备份MSI在某些情况下仍然有用，尤其是在其他一些未遵循最佳实践且您需要确定更改内容的情况下。
这是一个非常开放的问题，答案很大程度上取决于您所做的更改。以下是您应考虑的项目列表：
在大多数情况下，无需将MSI导入到BizTalk中就可以对现有工件进行较小的更改，例如业务流程代码/.net更改，管道组件，映射或架构更改。在这些情况下，只需安装MSI并重新启动主机即可。
在某些情况下，您可以仅添加特定的资源，而不必导入整个MSI。例如，如果您要添加新管道，以及为管道使用单独的程序集，则可以仅将管道程序集添加为使用新管道的资源。您可以通过其他方式管理其他工件。 BizTalk还支持并排部署程序集。这样做的关键是将工件放置在单独的程序集中
如果以上任何方法均无效，请考虑完全导入。
无论选择哪种部署方法，都必须在开发人员，qa环境中测试相同的方法，并在生产之前进行任何问题的捕捉。
希望获得帮助。您可以参考BizTalk部署上的其他链接。
- 谢谢，这真的很有帮助，我们做了很多细微的更改，正如您指出的那样，它起了作用，但是正如@Dijkgraaf指出的那样，这对于将来的部署是有风险的，所以我不会这样做。