2012-10-02 7 views
5

ダイナミックCRM 2011の場合、管理対象(または管理されていない)ソリューションとして変更内容をパッケージ化することにより、エンティティのカスタマイズをDEVからPRDに移行することが推奨されます。必要に応じてエンティティを削除できないため、アンマネージドは悪いです(ソリューションを削除するとコンテナのみが削除され、ソリューションに含まれるエンティティは残ります)。トレーニング中のほとんどのラボの例では、システムをカスタマイズし、カスタマイズされたエンティティを管理されたソリューションとしてエクスポートして、プロダクションにインポートします。このソリューションベースのアプローチはきれいで、PRDの内容を制御したり、関連するエンティティをバンドルしたり、依存関係を追跡したりするのが簡単になります。Dynamics CRM 2011:マネージドソリューションまたはDEVからPRDへの変更の適用

ただし、DEVサーバーで組織をダンプし、PRDから復元する必要がある場合(データ固有の問題を解決するなどの理由から)があります。これを無効にしてからDEV組織を削除し、次にDBAチームにプロダクションからCRMデータベースを復元するように依頼し、次にorgをDEVサーバーにインポートします。しかし、この「管理ソリューション」ベースの移行移行プロセスを実装すると、DEVをダンプしてPRDから再作成した後、エンティティを変更する機能を失うことはありません。これらのソリューションは読み取り専用モードです。これらのマネージドソリューションでカスタマイズを有効にすると、ソリューション全体に新しいエンティティを追加したり、ソリューション全体を削除せずにソリューション内からエンティティを削除したりできますか?管理ソリューションは単一のコード単位として扱われると考えていたので、すべてを削除するか、削除しないでください。どのように他の人がこの問題を解決したかを知ることに興味があります。

答えて

2

これを処理した方法の1つは、構成マスターを構成管理に使用する別個のクリーンなデバイスを使用することです。そのマシンは他の開発者やテスト作業には使用されません。 plugsinなどの開発マシンはprodから再構築できますが、このマシンは引き続きすべてのソリューションのマスターになります。理想的なソリューションではありませんが、マネージドソリューションをアンマネージド(おそらくパスワード機能を介して)に変換できるという「機能のギャップ」を避けることができます。

2

これらのタイプの開発者は、 〜に対処する状況。

これが不明な場合は、開発環境のエンティティを削除して運用環境に変更を公開してください。

解決策は、CRMがソリューション内で削除されたフィールドとエンティティを削除しないことを意味します。

エンティティを削除する唯一の方法は、ソリューションをアンインストールして、ソリューションでカバーされているすべてのエンティティの実動データを削除することです。

解決策は理論的には完全であるように見えますが、サードパーティのベンダーにとっては便利です。

あなたのソリューションをアンインストールすることにより、ロールバックすることができbeeingての目標は、パイプの夢です。データ変換を伴うデータモデルの更新を考えてみましょう。魔法の機能はそれを逆転させません。

バックアップを復元するのははるかに簡単で信頼性の高い方法です。