我现在正在学习很多关于托管解决方案和非托管解决方案的知识，我肯定会看到使用托管解决方案在生产中获得很多好处。
我看到推荐的模式是拥有一个开发环境，您可以在其中使用非托管解决方案，导出解决方案的非托管和托管版本，最后将托管解决方案部署到生产环境（可能首先用于测试暂存环境） ）。
这一切都非常好，干净，但并非没有陷阱。我最近遇到了以下情况：
我们使用上述模式为帐户实体创建和部署托管解决方案，并为客户安装。该解决方案包含一个表单和一些其他用于与遗留系统集成的东西
草图：
管理部分
字段A字段B
Field C Field D
在我不知情的情况下，客户继续使用“自定义”菜单自定义帐户表单。他所做的是创建一个新的表单部分，并将我们的托管解决方案中包含的一些自定义字段从原始部分移动到新部分
草图：
非管理部分
字段A字段B
管理部分
Field C Field D
由于这是一个非托管更改，它优先于我的托管更改，在我做了一些其他更改（删除其他字段并更改表单上某些字段的顺序）后，破坏了对表单布局的破坏。
我当然尝试重新安装解决方案，同时使用“覆盖自定义”选项，该选项承诺覆盖对实体的非托管自定义，但这不会改变任何内容。
我还尝试删除新部分和作为非托管自定义移动的字段（使用自定义菜单），然后重新安装托管解决方案，希望这会以某种方式“撤消”非托管更改，并且diff机制会检测到有问题的字段仅出现在托管解决方案中，这会导致它们出现在原始位置。但事实证明，它似乎只是在雕刻更多的石头 - 这次告诉系统从表格中删除字段。
真的可以这样吗，一旦你对表单进行了非托管更改，你的托管表单就搞砸了吗？
是否无法强制托管表单再次获得优先权？
我当然可以对表单进行一些更多的非托管自定义，以便将字段放回原来的位置，但这只会推迟问题，直到下次我想要...更改托管表单中字段的顺序 - 上次的非托管更改仍具有优先级。
似乎我唯一的选择是从头开始，或者切换到帐户实体的非托管机制。
如果这看起来很糟糕，我应该使用托管属性来禁止在托管解决方案中对表单进行自定义。如果这是一个自定义实体，我会这样做，但我认为这对于像帐户实体这样的实体来说会有点严格。获得的另一个教训可能是永远不会给客户sysadmin / customizer权限......
会对此有一些其他的想法和经验。
答案 0 :(得分：5)
我知道我在这里参加派对已经迟到了，但是对于它的价值而言，对于任何遇到这篇文章的人，我都会加上我的两分钱。我们有一个几乎与@TMan提到的设置，除了我们有一个Dev，QA和生产站点，其中Dev是不受管理的，我们的自定义和QA和生产的来源都是管理的。我花了很多时间来处理解决方案和自定义分层流程，以了解所有内容是如何组合在一起以获得最终结果的。我还添加了第三方托管解决方案。看到所有这些的最终结果，我得出结论，托管解决方案绝对不是可行的方式，除了可能是第三方解决方案提供商，但目标系统恕我直言应该全部定制与非托管更改。我发现的一个主要问题是，当我将第三方托管解决方案引入我们的Dev环境时，一旦我们将自己的自定义导出为托管解决方案以部署到QA和生产，我们将依赖于该解决方案中的组件。有趣的是，一旦您转到QA或生产托管站点，Dev站点上的分层和依赖关系就会以相反的顺序翻转，因为您自己的自定义设置从非托管到托管，并且托管自定义按安装顺序应用系统中的日期。在这里没有详细介绍，总结是这些依赖关系一旦被引入其中一个托管环境就永远不会消失，除非你想要数据丢失，否则你无法卸载自己的自定义，在某些情况下你可能无法即使您因为依赖性而导致数据丢失，也可以卸载解决方案。我们所有的环境都是CRM Online，所以我们没有选择直接在数据库中捣乱以摆脱我们不想要的东西。这里的关键是要知道，在大多数情况下，一旦你将托管解决方案放在适当位置，它永远存在，永久存在，你只能在那里存在额外的非托管更改，你将无法清理未使用或不需要的组件。我花了很多时间做自己的研究和测试，并花了很多时间与微软通电话。
底线：多站点设置的托管解决方案，例如Dev to QA和/或制作是一种非常糟糕的方式，你失去了灵活性，可能会碰到砖墙在某些情况下。你最好不要让所有东西都不受管理，并且拥有你期望正确定制系统的灵活性