对于Dynamics CRM 2011，Microsoft建议通过将更改打包为托管（或非托管）解决方案，将实体自定义从DEV移动到PRD。非托管是不好的，因为您无法在需要时删除实体（删除解决方案只删除容器，解决方案中包含的实体仍然存在）。在培训期间的大多数实验示例中，您将自定义系统，然后将自定义实体导出为托管解决方案，然后将其导入生产中。这种基于解决方案的方法很简洁，可以更容易地控制PRD中的内容，将相关实体捆绑在一起，跟踪依赖性等，所以我明白了。
但是，有时您需要在DEV服务器上转储组织并从PRD恢复（以解决特定于数据的问题或其他原因）。我们这样做是通过禁用，然后删除DEV组织，然后要求DBA团队从生产中恢复CRM数据库，然后我们将组织导回DEV服务器。但是，如果我们实施这种基于“托管解决方案”的变更迁移流程，在我们转储DEV并从PRD重新创建它后，我们是否会失去更改我们实体的能力，这些解决方案处于只读模式？如果我们在这些托管解决方案中启用自定义，我们是否能够在解决方案中添加新实体或从解决方案中删除实体而不删除整个解决方案？因为我认为托管解决方案被视为一个单独的代码单元，所以它要么全部删除，要么全部删除。有兴趣了解其他人如何解决这个问题。
答案 0 :(得分：2)
我们处理此问题的一种方法是使用单独的干净开发机器，我们将其用作“配置主机”来管理配置。该机器不用于任何其他开发或测试工作。用于插件等的开发机器可以从prod重建，但是这台机器仍然是所有解决方案的主人。不是一个理想的解决方案，但它确实避免了能够将托管解决方案转换为非托管（可能通过某些密码设施）的“功能差距”
答案 1 :(得分：2)
我建议不要在这些类型的dev-to-testing-to-prod情况下使用解决方案。
如果您对此不确定，请尝试删除开发环境中的实体并将更改发布到您的生产环境。
解决方案具有包容性意味着CRM不会删除解决方案中删除的字段和实体。
删除实体的唯一方法是卸载解决方案，从而删除解决方案涵盖的所有实体中的生产数据！
虽然理论上解决方案似乎很完美，但它们仅对第三方供应商有用。
通过卸载解决方案来实现回滚的目标是一个梦想。考虑涉及数据转换的数据模型更新。没有任何神奇的功能可以扭转它。
恢复备份更加简单可靠。