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

EN

首先，尽可能避免系统表中的直接DB更新。你永远不知道什么时候它会袭击你(下一个解决方案导入，下一个CRM升级，移动到云，等等)。

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

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

在安全的环境中恢复prod组织和播放的全过程是个好主意。

哇，这是个棘手的问题。由于您提到了直接更新表，我将假设系统是-prem。

在托管解决方案之外的托管解决方案中注册一个插件是我从未做过的事情，虽然我已经直接更新了插件登记表，但它肯定是要最小化的。

尽管听起来很不愉快，但要想以一种支持的方式回到一个良好的状态，你可能不得不：

备份SQL数据库

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

撤消托管解决方案上的所有依赖项(即编辑所有工作流，使它们不再依赖托管解决方案)。为了减轻这部分的痛苦，您可能需要尝试通过非托管解决方案导出受影响的工作流。然后，您可以删除它们，而不是试图清除依赖项。然后，在系统中返回托管解决方案之后，理论上可以导入非托管工作流解决方案来恢复工作流。但是，必须承认，这项工作依赖于工作流，即通过名称而不是Id查找它们所依赖的插件程序集，我不确定情况是这样的--就像我说的，实验。

注销“带外”插件。

卸载托管解决方案

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

还原/重新配置工作流

还原托管实体数据

很多..。事实上，我会考虑打开一张Microsoft支持票，看看他们是否可以提供其他方法来纠正这种情况。

在这种情况下，我个人还可能考虑不受支持的方法，比如在删除托管解决方案之前使用SQL复制任何托管实体的表，然后在托管解决方案修复后使用SQL复制数据。当然，我(几乎)从来不建议以一种不受支持的方式使用SQL，所以请自己冒险(以及大量的备份)探索这个选项。