手动插件注册 - 托管解决方案

Question

我对第三方通过托管解决方案加载的第三方插件的注册/更新有一些疑问。

我们遇到的问题是他们（第三方）向我们发送了一个插件更新和管理解决方案之外的新插件，让我们通过注册工具手动注册它。然后，下次我们尝试导入其解决方案的更高版本时，托管解决方案导入失败。我们最终意识到pluginassembly和pluginassemblytype表中的重复行分别具有相同的Pluginassemblyid和plugintypeid以及不同的solutionid。

这些解决方案是＆＃34; Active＆＃34;我认为这来自人工注册和＆＃34; IPM Global＆＃34;这是我们的第三方管理解决方案。我们成功获得导入解决方案的唯一方法是更改​​覆盖时间 在表格上为0，然后删除＆＃34; Active＆＃34; pluginassembly和plugintype记录。

还有其他方法可以完成同样的事情吗？

顺便说一句。我们在尝试之前尝试取消注册插件，但我们的工作流程中存在太多依赖项。

Answer 1

哇，这是一个棘手的问题。由于您提到直接更新表，我假设系统是在本地。

在托管解决方案之外注册存在于该托管解决方案之外的插件是我从未做过的事情，虽然我直接更新了插件注册表，但它肯定是最小化的。

听起来不愉快，要以支持的方式回到良好的状态，你可能会看到：

备份SQL数据库

备份来自任何托管解决方案实体的所有数据。

撤消托管解决方案的所有依赖关系（即编辑所有工作流，使其不再依赖托管解决方案）。为了减轻这篇文章的痛苦，您可能希望尝试通过非托管解决方案导出受影响的工作流。然后你可以删除它们而不是试图清除依赖项。然后，在将托管解决方案恢复到系统后，理论上可以导入非托管工作流解决方案以恢复工作流。但是，诚然，这种工作取决于工作流程找到他们依赖于名称而不是Id的插件组件，我不确定是这种情况 - 就像我说的那样，实验。

取消注册＆＃34;带外＆＃34;插件

卸载托管解决方案

安装托管解决方案的干净副本，包括以前有问题的插件。

恢复/重新配置工作流程

还原托管实体数据

很多......事实上，我会考虑打开微软支持票，看看他们是否可以提供任何替代方法来纠正这种情况。

在这种情况下，我个人可能还会考虑不支持的方法，例如在删除托管解决方案之前使用SQL复制任何托管实体的表，然后在修复托管解决方案后使用SQL将数据复制回来。当然，我（几乎）从不建议以不支持的方式使用SQL，因此请自行承担风险（并使用大量备份）来探索该选项。

Answer 2

首先，尽可能避免在系统表中进行直接数据库更新。你永远不知道什么时候它会打击你（下一个解决方案导入，下一个CRM升级，迁移到云等）。

我假设您的供应商解决方案包含实体和属性，而不仅仅是包含SDK消息处理步骤的程序集。因此，您不能简单地删除该托管解决方案，因为会导致数据丢失。另外我假设它们的程序集中没有工作流程活动。

通过正确注册的程序集和SDK消息处理步骤向他们询问解决方案。然后使用插件注册工具（https://msdn.microsoft.com/en-us/library/gg309580.aspx）进入您的组织并取消注册其程序集。然后导入他们最新的解决方案。它应该能够用它们内部的任何东西导入它们的组件。

首先在安全的环境中恢复生产组织的副本并完成整个过程是个好主意。