目標: ProtectedConfigurationProvider から継承するクラスの Initialize メソッドの呼び出し中に、.NET Framework 4.5 で実行中の ASP.NET Web アプリケーションの BaseDirectory を見つけます。
問題: .NET Framework 4.5 では、ProtectedConfigurationProvider クラスが実行されるドメインが変更されました (また、アプリケーションのライフサイクルでクラスが呼び出される場合もあるでしょうか?)
.NET Framework 4.5 をインストールする前は、「AppDomain.CurrentDomain.BaseDirectory」を使用して、ProtectedConfigurationProvider から継承するクラスの Initialize または Decrypt メソッド中に取得できました。これは、「c:\inetpub\wwwroot\xyz\」のように解決されます。
.NET Framework 4.5 をインストールした後、Initialize または Decrypt メソッド中に、「AppDomain.CurrentDomain.BaseDirectory」は「C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\10.0\」の行に沿って解決されます。
ユース ケース: web.config/app.config からの構成データの呼び出しを、カスタム "ProtectedConfigurationProvider" クラスを使用して、アプリケーション ディレクトリ内のカスタム構成ファイルにリダイレクトします。(例: http://www.wrox.com/WileyCDA/Section/Redirecting-Configuration-with-a-Custom-Provider.id-291932.html または https://github.com/kellyhughes/ConfigPTFE )。これは、「configProtectionProvider」属性を持つ構成ノードで使用されます。このライブラリは、さまざまな種類のアプリケーション (例: winforms、wpf、windows サービス、web アプリケーション) によって使用されています。上記の問題は、web アプリケーションのコンテキストでのみ発生します。
注：情報を収集するためにフォールバックすることがわかっているほとんどのオブジェクトは、このメソッドが呼び出される時点でnullです。たとえば、HttpContext と Server.MapPath は、現時点では存在しないように見えるため、役に立ちません。そして、はい、メインの構成から構成ファイルを分離する他の方法があることも知っています。このカスタム ライブラリは、「file」属性や「configSource」属性などを使用することによって提供されない追加機能を提供します。