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

关于第三方先前通过托管解决方案加载的第三方插件的注册/更新，我有一些问题

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

这些解决方案ID是“活动”的，我认为它们来自手动注册和“IPM Global”，这是我们的第三方管理解决方案。我们成功导入解决方案的唯一方法是更改覆盖时间 将表上的值设置为0，然后删除“活动”插件程序集和插件类型记录

有没有其他方法可以完成支持的相同任务

---

顺便说一句，我们在尝试之前确实尝试过注销插件，但是我们的工作流中有太多依赖项

哇，这是个棘手的问题。因为您提到直接更新表，所以我假设系统是on-prem

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

尽管听起来很不愉快，但要以支持的方式回到良好状态，您可能需要：

备份SQL数据库

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

撤消对托管解决方案的所有依赖关系（即编辑所有工作流，使其不再依赖托管解决方案）。为了缓解这一问题，您可能需要尝试通过非托管解决方案导出受影响的工作流。然后您可以删除它们，而不是试图删除依赖项。然后，在将托管解决方案返回系统后，理论上可以导入非托管工作流解决方案以恢复工作流。但是，不可否认，这项工作依赖于工作流通过名称而不是Id找到它们所依赖的插件程序集，我不确定情况是否如此——就像我说的，实验

注销“带外”插件

卸载托管解决方案

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

恢复/重新配置工作流

恢复托管实体数据

有很多。。。事实上，我会考虑打开一张微软的支持票，看看他们是否能提供任何其他方法来纠正这种情况。p>

---

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

首先，尽可能避免在系统表中直接更新数据库。你永远不知道什么时候会受到影响（下一次解决方案导入、下一次CRM升级、移动到云等）

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

要求他们提供具有正确注册的程序集和SDK消息处理步骤的解决方案。然后使用pluginregistration tool（）进入您的组织并注销其程序集。然后导入他们的最新解决方案。它应该能够导入其中包含任何内容的程序集

---

最好先恢复产品组织的副本，并在安全的环境中完成整个过程。

下次，请您的供应商向您提供带有更新插件建议的托管解决方案。谢谢你的回复。