0

私は、既存の .Net アプリケーション用の API を作成しています。そのアプリケーションを他のカスタム アプリケーション (顧客が作成した可能性があります) の「エンジン」として使用するためです。前提は、「エンジン」が常にインストールされ、ターゲット マシンで動作することです。

私のアプローチは、「エンジン」アプリケーション用の VS ソリューションで新しいプロジェクトを作成することです。これは、アプリケーション独自のライブラリのきめ細かな機能をより高いレベルに集約するためのパブリック メソッドを提供するクラス ライブラリであり、サード パーティ アプリケーションの単純化されたメソッド呼び出しです。使用する著者。

API は「エンジン」ソリューションのコンテキストで適切に機能し、単体テストは正しく機能します。ただし、必要なサービスを提供する API への参照を使用して、その VS ソリューションの外部で単純な「カスタム」アプリケーションを作成しようとすると、カスタム アプリケーションに「エンジン」のコピーがない限り、問題が発生します。app.config (sic) ファイルがコンパイルされる前に、エンジンがその構成ファイルにアクセスしようとすると、例外がスローされます。

サード パーティの開発者が app.config ファイルを手に入れることを期待するのは明らかに非現実的であり、エンジンの構成ファイルをソリューションにコピーして名前を変更する必要があると期待するのは少し洗練されていません。

これを行うためのよりクリーンな方法はありますか?その目的は、カスタム アプリケーションが API アセンブリへの参照のみを必要とし、エンジンが通常どおりに使用されているかのように「動作する」ようにすることです。できれば、バイナリ リモーティング、Web サービス、および COM は避ける必要があります (これらで問題が解決すると仮定して)。

ああ、これはすべて.Net 3.5 & VS2008 TIAです

4

1 に答える 1

0

はい、NuGet を使用します。アセンブリを NuGet パッケージにパッケージ化すると、エンジンの構成プロパティを自動的に追加/更新する構成ファイル変換を追加できます。次に、消費者が参照をプルすると (ローカル NuGet サーバーから?)、アセンブリ参照と構成変換が取得されます。

NuGet パッケージでのみ構成を管理していることがわかるように、エンジンの正式な構成セクションを作成することをお勧めします。

于 2013-03-01T11:41:19.047 に答える