最近、マネージドソリューションとアンマネージドソリューションについて多くのことを学んでおり、本番環境でマネージドソリューションを使用することで多くのメリットが確実に得られます。
推奨されるパターンは、アンマネージドソリューションを使用し、アンマネージドバージョンとマネージドバージョンの両方のソリューションをエクスポートし、最後にマネージドソリューションを本番環境に（場合によっては最初にテストのためにステージング環境に）展開する開発環境にすることです。
これはすべて非常に素晴らしく、きれいですが、落とし穴がないわけではありません。私は最近、次のシナリオを経験しました。
1.1。
上記のパターンを使用して、アカウントエンティティのマネージドソリューションを作成および展開し、顧客にインストールしました。このソリューションには、特に、レガシーシステムと統合するためのフォームやその他のものが含まれていました。
スケッチ：
管理セクション
フィールドAフィールドB
フィールドCフィールドD
2.2。
私の知らないうちに、顧客は先に進み、「カスタマイズ」メニューを使用してアカウントフォームをカスタマイズしました。彼がしたことは、新しいフォームセクションを作成し、マネージドソリューションに含まれるカスタムフィールドの一部を元のセクションから新しいセクションに移動することでした。
スケッチ：
管理されていないセクション
フィールドAフィールドB
管理セクション
フィールドCフィールドD
3.3。
これは管理されていない変更であるため、管理された変更よりも優先され、他の変更を行った後、フォームのレイアウトに大混乱をもたらします（他のいくつかのフィールドを削除し、フォーム上のいくつかのフィールドの順序を変更します）
解決の試み：
もちろん、ソリューションを再インストールしようとしましたが、エンティティの管理されていないカスタマイズを上書きすることを約束する「カスタマイズの上書き」オプションも使用しましたが、何も変更されません。
また、（カスタマイズメニューを使用して）管理されていないカスタマイズとして移動された新しいセクションとフィールドを削除してから、管理されたソリューションを再インストールしてみました。これにより、管理されていない変更が何らかの形で「元に戻され」、diffメカニズムがそれを検出することを期待しています。問題のフィールドは管理対象ソリューションにのみ存在し、これにより元の場所に表示されます。しかし、結局のところ、私は石にさらに多くの変更を加えているように見えます。今回は、フォームからフィールドを完全に削除するようにシステムに指示しました。
フォームに管理されていない変更を加えると、管理されたフォームがねじ込まれてしまうというのは、本当にこのようなことでしょうか。
管理対象フォームを強制的に優先させる方法はありませんか？
もちろん、フォームに管理されていないカスタマイズをいくつか行って、フィールドを元の場所に戻すこともできますが、それは、次に管理されたフォームのフィールドの順序を変更したいときまで問題を延期します-管理されていない変更は前回はまだ優先されます。
私の唯一の選択肢は、最初からやり直すか、アカウントエンティティの管理されていないレジームに切り替えることだと思われます。
学んだ教訓：
これが見た目と同じくらい悪い場合は、管理対象プロパティを使用して、管理対象ソリューションのフォームのカスタマイズを禁止する必要があります。これがカスタムエンティティの場合はそうしますが、アカウントエンティティのようなエンティティには少し厳しいと思いました。学んだもう1つの教訓は、おそらく顧客にsysadmin/customizer権限を決して与えないことです...
これに関する他のいくつかの考えや経験が大好きです。