3

C＃4.0で記述されたASP.NETWebアプリケーションがあります。アプリケーションは、独自の構成ファイルに付属するクラスライブラリを参照します。実行時に、クラスライブラリは次のコードと同様のコードを使用してこの特定の構成をロードします。

var exeConfigPath = this.GetType().Assembly.Location;
var config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);

これが行われるのは、ライブラリがアプリケーション構成ではなく、バンドルされた構成をロードする必要があるためです。アプリケーション構成は、ライブラリの設定に関係してはならず、それらを変更できないようにする必要があります。

さて、この概念が機能するために実行する必要がある他のいくつかのことがあります。ライブラリの構成ファイルのビルド操作をプロパティウィンドウでコンテンツとして設定し、コピーをCopy Alwaysまたはに設定する必要がありCopy If Newerます。これまでのところ、ファイルは自動的にクラスライブラリのbinディレクトリとWebアプリケーションのbinディレクトリの両方に配置され、からに正しく名前が変更さApp.configれCustomLibrary.dll.configます（想定どおり、ライブラリのdllはCustomLibrary.dllです）。

今、私は2つの問題に直面しています。

1）Webアプリケーションをファイルシステムの場所（IISでマップされている）に公開すると、公開されたアプリのbinフォルダーのようにCustomLibrary.dll.config表示されます。App.configOK-予想される規則に一致するようにクラスライブラリプロジェクトで名前を変更します-そして問題は解決しました。

2）公開されている場合でも、IISはアプリケーションを再度コンパイルし、ASP.NET一時ファイルに保存します。参照される各アセンブリ専用のフォルダを備えた豪華なディレクトリ構造があります。CustomLibrary.dllに対応するフォルダーには、構成ファイルが含まれていません。this.GetType().Assembly.Locationは一時フォルダへのパスを返すため、アプリケーションは構成のロードに失敗し、正常にクラッシュします。

クラスライブラリに構成を含めるパターンを保持し、Webアプリケーションで機能させる必要があります。.configをtempフォルダーに手動でコピーすると、アプリは機能しますが、ランダムな名前のフォルダーに手動でコピーするのは本当に嫌いです。

IISが一時フォルダーを使用しないようにする方法、または構成ファイルに沿ってコピーする方法はありますか？私が直面している問題は、構成ファイルが配置されているときにアプリケーションが期待どおりに機能するため、概念ではなく構成に関連していると思います。構成ファイルへのハードコードされた物理パスを使用することも避けたいと思います。

編集：

わかりやすくするために、何を、なぜ達成したいのかを指摘します。ライブラリとWebプロジェクトは別々の製品として開発されるという考え方です。ライブラリの構成にはユーザーまたはアプリケーション固有の情報がないため、さまざまな使用シナリオで変更されることはありません。また、エンドアプリケーションではなく、クラスライブラリの機能に固有のものです。ライブラリの構成情報をライブラリ内にバンドルしておくことは理にかなっています（Javaと同様に、Springコンテキストのxmlファイルまたはプロパティファイルがライブラリのjarにバンドルされます）。コンシューマーアプリケーションの各アプリ/ウェブ構成の構成をコピーする必要がないようにしたいと思います。コンシューマーアプリケーションがサードパーティによって開発されている場合がありますが、そして、私は彼らが私のものが機能するために彼らの構成を正しく行うことに依存したくありません。繰り返しますが、ここでの唯一の問題は、構成ファイルが適切な場所にコピーされていないことです。

4

3 に答える 3

1

私は説明された問題を回避する方法に沿ってやって来ましたが、それでも私の要件にはあまり満足のいくものではありません。

解決策は、常に利用可能なアプリケーション構成（Webアプリのweb.config、またはapp.config）を利用することです。各ライブラリの構成ファイルへの絶対パスを設定として追加しました。だから私は結局：

<!--
THIS IS IN THE WEB.CONFIG FILE
-->
<appSettings>
    <add key ="ClassLibrary_ConfigPath"
         value ="{My Publish Output Folder}\ClassLibrary.dll.config"/>
</appSettings>

クラスライブラリは、次のコードを使用して構成をロードするようになりました。

Configuration config = null;
try 
{
    var exeConfigPath = this.GetType().Assembly.Location;
    config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
catch (Exception e)
{
    if (!IsConfigurationNotFoundError(e)) 
    {
        // IsConfigurationNotFoundError logic skipped for brevity
        var exeConfigPath = 
            ConfigurationManager.AppSettings["ClassLibrary_ConfigPath"];
        if (exeConfigPath != null) 
        {
            config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
        }
    }
    else
    {
        throw;
    }
}

これは機能しますが、可能であればより良い解決策を待ちます。それでも、ClassLibrary.dll.config全体をweb.configファイルにコピーする必要はありませんが、ファイルシステムの場所を管理し、アプリ設定名に注意する必要があります。私が本当に望んでいるのは、ClassLibrary.dllのコンシューマーアプリがその構成をまったく処理しないことです。デスクトップアプリの場合、Visual StudioがClassLibary.dll.configを適切にコピーするので、これについて説明します。Webアプリでスムーズに動作させる方法があるといいのですが。

于 2013-03-15T23:06:42.837 に答える
1

それらが静的な内部設定であり、誰も見たり変更したりしてはならない場合は、クラスライブラリに埋め込まれたリソースとして構成が含まれているファイルを用意したほうがよいでしょうか。それか、設定を含む静的クラスのいずれかです。

そうすれば、誰もそれを変更しないことを確信できます。これは、シナリオではプラスのようです。

于 2013-03-15T23:20:28.643 に答える
0

簡単な答えは：あなたはできません。両方の構成セクションをマージし、すべての設定をアプリケーションのメイン構成ファイルに配置する必要があります。Webアプリケーションの場合は、になりますweb.config。これを読む

于 2013-03-15T01:36:53.950 に答える