这些天我学到了很多关于托管和非托管解决方案的知识，我肯定会看到在生产中使用托管解决方案的很多好处。
我看到推荐的模式是拥有一个开发环境，您可以在其中使用非托管解决方案，导出解决方案的非托管和托管版本，最后将托管解决方案部署到生产环境(可能首先部署到临时环境以进行测试).
这一切都很好很干净，但并非没有陷阱。我最近经历了以下场景:
1.
我们使用上述模式为帐户实体创建和部署托管解决方案，并为客户安装。该解决方案除其他外还包含一个表单和一些其他用于与遗留系统集成的东西
素描:
托管部分
字段 A 字段 B
字段 C 字段 D
2.
在我不知情的情况下，客户继续使用“自定义”菜单自定义帐户表单。他所做的是创建一个新的表单部分，并将我们的托管解决方案中包含的一些自定义字段从原始部分移动到新部分
素描:
非托管部分
字段 A 字段 B
托管部分
字段 C 字段 D
3.
由于这是一个非托管更改，它优先于我的托管更改，在我做了一些其他更改(删除一些其他字段并更改表单上某些字段的顺序)后破坏了表单布局
解析尝试:
当然，我已经尝试重新安装该解决方案，也尝试使用“覆盖自定义”选项，该选项 promise 覆盖实体的非托管自定义，但这并没有改变任何东西。
我还尝试删除作为非托管自定义(使用自定义菜单)移动的新部分和字段，然后重新安装托管解决方案，希望这会以某种方式“撤消”非托管更改并且差异机制会检测到有问题的字段仅存在于托管解决方案中，并且这会导致它们出现在原始位置。但事实证明，我似乎只是在刻画更多变化 - 这次告诉系统从表单中完全删除字段。
真的可以这样吗，一旦您对表单进行了非托管更改，您的托管表单就完蛋了？
有没有办法强制托管表单再次获得优先权？
我当然可以对表单进行更多非托管自定义，以将字段放回原来的位置，但这只会将问题推迟到下次我想要的时候，例如更改托管表单中的字段顺序 - 上次的非托管更改仍然具有优先权。
看来我唯一的选择是要么从头开始，要么切换到帐户实体的非托管制度。
经验教训:
如果这真的像看起来那样糟糕，我可能应该使用托管属性来禁止对我的托管解决方案中的表单进行自定义。如果这是一个自定义实体，我会这样做，但我认为这对于像帐户实体这样的实体来说有点严格。吸取的另一个教训可能是永远不要授予客户系统管理员/定制员权限...
会喜欢关于此的一些其他想法和经验。
最佳答案
我知道我参加这里的聚会迟到了，但是对于它的值(value)以及看到这篇文章的任何人，我会加两分钱。我们的设置几乎与@TMan 提到的完全一样，只是我们有一个开发、QA 和生产站点，其中 Dev 不受管理，而我们的定制源和 QA 和生产都受到管理。我在解决方案和自定义分层过程中花费的时间比我希望的要多得多，以了解所有内容如何组合在一起以获得最终结果。我还添加了第三方托管解决方案。看到所有这一切的最终结果，我得出的结论是托管解决方案绝对不是可行的方法，除了第三方解决方案提供商，但恕我直言，目标系统都应该使用非托管更改进行定制。我发现的一个主要问题是，当我将第三方托管解决方案引入我们的开发环境时，一旦我们将自己的定制导出为托管解决方案以部署到 QA 和生产环境中，我们将依赖该解决方案中的组件。有趣的是，一旦您转到 QA 或生产托管站点，开发站点上的分层和依赖项就会以相反的顺序翻转，因为您自己的自定义从非托管变为托管，并且托管自定义按安装顺序应用系统中的日期。此处无需详细介绍，总而言之，这些依赖项一旦引入其中一个托管环境就永远不会消失，除非您希望丢失数据，否则您无法卸载自己的自定义设置，在某些情况下您可能无法卸载即使您对由于依赖项导致的数据丢失没有问题，也可以卸载解决方案。我们所有的环境都是 CRM Online，所以我们没有选择直接在数据库中乱搞来摆脱我们不想要的东西。这里的关键是要知道，在大多数情况下，一旦您将托管解决方案放置到位，它就会永远、永久地存在，并且您只能在现有内容之上应用其他非托管更改，您将无法清理未使用或不需要的内容成分。我花了很多时间进行自己的研究和测试，也花了很多时间与 Microsoft 通电话。
底线:多站点设置的托管解决方案(例如从开发到 QA 和/或生产)是一种非常糟糕的方式，您会失去灵 active 并且可能会碰壁在某些情况下。你最好让一切都不受管理，并拥有你期望的灵 active 来正确定制你的系统
关于forms - 客户关系管理 2011 : Unmanaged changes to managed solution form gotcha，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14197111/