5

对于 Dynamics CRM 2011，Microsoft 建议通过将更改打包为托管（或非托管）解决方案，将实体自定义从 DEV 转移到 PRD。非托管很糟糕，因为您无法在需要时删除实体（删除解决方案只会删除容器，解决方案中包含的实体仍然存在）。在培训期间的大多数实验室示例中，您将自定义系统，然后将自定义实体导出为托管解决方案，然后将其导入生产。这种基于解决方案的方法很干净，可以更轻松地控制 PRD 中的内容、将相关实体捆绑在一起、跟踪依赖关系等，所以我明白了。

但是，有时您需要将组织转储到 DEV 服务器上并从 PRD 恢复（以解决特定于数据的问题或出于其他原因）。我们通过禁用，然后删除 DEV 组织，然后要求 DBA 团队从生产中恢复 CRM 数据库来做到这一点，然后我们将组织导入回 DEV 服务器。但是，如果我们实施这种基于“托管解决方案”的变更迁移过程，在我们转储 DEV 并从 PRD 重新创建它之后，我们是否会失去更改实体的能力，这些解决方案处于只读模式？如果我们在这些托管解决方案中启用自定义，我们是否能够在不删除整个解决方案的情况下向解决方案添加新实体或从解决方案中删除实体？因为我认为托管解决方案被视为单个代码单元，所以要么全部删除，要么不删除。

4

2 回答 2

2

我们处理这个问题的一种方法是使用一个单独的干净的开发机器，我们用它来管理配置作为“配置主机”。该机器不用于任何其他开发或测试工作。插件等的开发机器可以从 prod 重建，但是这台机器仍然是所有解决方案的主机。不是一个理想的解决方案，但它确实避免了能够将托管解决方案转换为非托管解决方案的“功能差距”（可能通过一些密码工具）

于 2012-10-03T09:59:33.337 回答
2

我建议不要在这种从开发到测试到生产的情况下使用解决方案。

如果您对此不确定，请尝试在您的开发环境中删除一个实体并将更改发布到您的生产环境。

解决方案具有包容性，这意味着 CRM 不会删除在您的解决方案中删除的字段和实体。

删除实体的唯一方法是卸载您的解决方案，因此删除您的解决方案涵盖的所有实体中的生产数据！

虽然理论上解决方案看起来很完美，但它们只对第三方供应商有用。

通过卸载您的解决方案来回滚的目标是一个白日梦。考虑一个涉及数据转换的数据模型更新。没有神奇的功能可以扭转这一点。

恢复备份要简单得多且可靠得多。

于 2013-04-30T21:02:49.293 回答