13

わかりました、これはかなり単純ですが、私が見たところによると、ある種の Windows ワークフローを使用して、別の構成を別の構成に含めることしかできません (私はこれを拒否します)。

契約は次のとおりです。

MAINAPP.EXE 仮想の LIBRARY.DLL を参照します。

MAINAPP.EXE には独自の MAINAPP.EXE.config があります。

「構成値」を LIBRARY.DLL に追加すると (それによって LIBRARY.DLL プロジェクトに app.config が作成されます)、app.config を LIBRARY.DLL.config に正しいパス ポストにコピーしても、これらの値は実行時に使用できません。 -ビルド。

上記の理由は、参照されているライブラリでさえ「mainapp.exe」構成から読み取るためです。

ここまでは順調ですね"。ここで、WCF サービスの参照を追加すると、ビジュアル スタジオは app.config を作成するか、bindings/endpoints/etc. を使用して設定します。ただし、それは参照の構成を追加したプロジェクトに追加されます。したがって、Library.DLL.prj は、読み取られず、出力ディレクトリにコピーされることもないため、機能しない素敵な app.configになります。app.config を右クリックして、「常にコピー」を true に設定できると思うかもしれません。忘れてください。それは何もしません。（あなたはそれをググることができます）。

上記の奇妙なシナリオを考えると、通常の VS2008 開発者は .NET 3.5 プロジェクトで作業して、ビジネス層 dll に追加する WCF サービス参照をどのように管理するのでしょうか? その開発者は、サービスに変更があるたびに、またはサービスを追加/削除するたびに、DLL の役に立たないapp.config から Mainapp.exe.config ファイルにすべてのセクションをコピーして貼り付けることになっていますか?

4

3 に答える 3

8

はい。コピー＆ペーストが答えです。これは素晴らしい答えではありませんが、それが答えであり、.NET 1.0 の初日から AppSettings を使用してきました。

于 2009-03-11T13:13:05.373 に答える
3

ライブラリプロジェクトにカスタム構成ファイルを含めることができ、それらのファイルを別のアプリケーションの実行可能場所にコピーできます（少し厄介ですが、それほど大したことではありません）。これらのファイルの情報を取得するには、OpenMappedExeConfigurationを使用する必要があります。次に、WCFプロキシをインスタンス化するときにカスタムコーディングを行う必要があります（バインディングをインスタンス化し、それをプロキシに渡します）。ここでのパーティーに遅れましたが、興味があれば詳細をお知らせします。

于 2009-05-26T05:42:39.593 に答える
0

いいえ、あなたは正しいです。

しかし、確かに、WCF サービスはビジネス レイヤー プロジェクトではなく、ビジネス レイヤーへのファサードとして機能する別のプロジェクトにあります。ビジネス レイヤーは、本来あるべき別のアセンブリであり、アクセス方法を気にしません。WCF プロジェクトがそれを行います。

またはもちろん、カスタム サービス ホストを作成し、最小限の情報 (ホスト名、証明書の拇印) を構成ファイルに入れ、残りをコードで行います。

于 2009-03-11T13:12:41.973 に答える