0

さまざまな構成を区別するのに苦労しています。少し説明させてください

シナリオ：

PとMなどの 2 つの AX プロジェクトがあり、どちらもProdRouteJobテーブルを変更して、独自のプロジェクト固有のクラスの 1 つでメソッドを呼び出しているとします。
もちろん、開発者のマシンにはこれらすべてのクラスがあり、ProdRouteJob正常にコンパイルされますが、新しいサーバーにインストールする場合は、インストールされていないすべてのプロジェクトにスタブ クラスを追加したくありませんか? したがって、これらの呼び出しをプロジェクト クラスに次のようにラップします。

if( Global::isConfigurationkeyEnabled( <projectPConfKey> ) )  
     // call project P stuff

それらをきれいにカプセル化します。すべてのプロジェクトの構成キーを宣言したら、準備完了ですよね?

ただし、このマシンにプロジェクトPをインストールしていない場合は、projectPConfKey不明であるため、エラーがスローされます。これで、すべてのインストールで、すべてのプロジェクトの構成キーをインストールして、サーバーに などがあることを伝えることができますが、projectPConfKeyこれらすべてifの は true と評価されます...

要するに、プロジェクトの XPO に構成キーを含めて、コードをコンパイルすると同時に、一部の構成キーが最初から無効になるようにするにはどうすればよいでしょうか?

それとも、私がここで見逃している完全に基本的なものがありますか?

編集：

回答のコンセンサス (demas に感謝、Kjeldsen 氏に感謝) は、マクロまたは構成キーを使用して多かれ少なかれ自動化されたクライアント側の構成を試みることは非現実的であるということです。したがって、クライアントにインストールするときは、変更を含む標準テーブルをインポートし、現在のインストールに関係のないすべての変更を手動で削除する必要があります。

Demas は私が尋ねた質問に答え、Mr. Kjeldsen は demas の回答の下のコメント会話で生じた質問に答えたので、どちらの答えを受け入れるか少し迷っています。ケルドセン氏に謝罪し、デマスの回答を承認済みとしてマークします。

4

2 に答える 2

1

通常、大規模なソリューション センター (VAR) には、モジュールごとに個別のアプリケーションがあります。2 つのモジュールがある場合、2 つのアプリケーションがあります。

優れたモジュールは、標準アプリケーションとの衝突領域が非常に小さく、これらは別のプロジェクトに保持されます。

標準および他のモジュールとの衝突は、インストール時に手動で処理されます。コリジョン エリアは小さく、めったに変化しないため (ビジネス ロジックを含むべきではありません)、問題は最小限に抑えられます。

于 2010-11-26T16:15:07.440 に答える
1 
if( Global::isConfigurationkeyEnabled( <projectPConfKey> ) )

このチェックは実行時のみ機能し、コードをコンパイルするとエラーが発生します。

そのため、実稼働サーバーにインポートしてプロジェクト M の変更のみをインポートする場合は、スタブ クラスを作成するか、オブジェクトを比較する必要があります。

別のアプローチがありますが、それを確認するための Axapta がありません。試す：

#if.never
someMissingCall();
#endif

しかし、それが今うまくいくかどうかはわかりません。

于 2010-11-26T10:53:53.357 に答える