这些天来，我学到了很多关于托管和非托管解决方案的知识，而且我肯定看到了在生产中使用托管解决方案的很多好处。
我看到推荐的模式是拥有一个开发环境，您可以在其中使用非托管解决方案，导出解决方案的非托管和托管版本，最后将托管解决方案部署到生产环境（可能首先部署到暂存环境进行测试）。
这一切都非常好和干净，但并非没有陷阱。我最近经历了以下场景：
1.
我们使用上述模式为帐户实体创建和部署托管解决方案，并为客户安装它。该解决方案包含一个表单和一些其他东西，用于与遗留系统集成
草图：
托管部分
字段 A 字段 B
字段 C 字段 D
2.
在我不知情的情况下，客户继续使用“自定义”菜单自定义了帐户表单。他所做的是创建一个新的表单部分，并将我们托管解决方案中包含的一些自定义字段从原始部分移动到新部分
草图：
非托管部分
字段 A 字段 B
托管部分
字段 C 字段 D
3.
由于这是一项非托管更改，因此它优先于我的托管更改，在我进行其他一些更改（删除一些其他字段并更改表单上某些字段的顺序）之后破坏了表单布局
解决尝试：
当然，我已经尝试重新安装解决方案，还使用“覆盖自定义”选项，该选项承诺覆盖实体的非托管自定义，但这不会改变任何东西。
我还尝试删除新部分和作为非托管自定义移动的字段（使用自定义菜单），然后重新安装托管解决方案，希望这会以某种方式“撤消”非托管更改，并且差异机制会检测到有问题的字段仅存在于托管解决方案中，这将导致它们出现在原始位置。但事实证明，我似乎只是在石头上刻下更多的变化——这一次是告诉系统从表单中完全删除字段。
真的可以这样吗，一旦您对表单进行了非托管更改，您的托管表单就被搞砸了？
有没有办法强制托管表单再次优先？
我当然可以对表单进行更多非托管自定义以将字段放回原来的位置，但这只会将问题推迟到下一次我想更改托管表单中字段的顺序 - 非托管更改上次还是有优先权。
看来我唯一的选择是重新从头开始，或者切换到帐户实体的非托管制度。
得到教训：
如果这看起来很糟糕，我可能应该使用托管属性来禁止对我的托管解决方案中的表单进行自定义。如果这是一个自定义实体，我会这样做，但我认为这对于像帐户实体这样的实体来说有点严格。另一个教训可能是永远不要给客户系统管理员/定制者权限......
希望有一些其他的想法和经验。