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