Visual StudioおよびIISExpressでデバッグするときにランタイムでWeb.configコンテンツを変更する

技術的には、この記事は新しいものではなく、特定の問題を解決するためのwinapiフックのもう1つの便利なアプリケーションです。



Visual StudioでWebプロジェクトを操作するとき、不快な些細なことが1つあります-開発プロセス中に複数のブランチを使用し、それぞれが環境の独自のコピー（データベース、または外部サービスなど）を使用する必要がある場合、デバッグ時に構成ファイルに問題があります-IISExpressは、プロジェクトフォルダー内のメインweb.configのみを使用します。通常、すべての接続文字列にはデフォルト値が含まれ、ブランチ固有の設定はなく、起動時に変換は適用されません。 もちろん、自動または手動で強制的にweb.configに変換を適用できますが、最初に、変更されたファイルは保留中の変更で常にハングします。これにより、不要な変更がコミットされて他のブランチに移動するリスクが生じ、次に多くのファイルが作成されます構成ファイルへの変更をコミットする前に、そのような変換を手動で削除する必要があるため、編集する際に不便です。



これを回避する方法を検討してください。



ソリューションは非常に簡単です-IISExpressプロセスによる構成ファイルの読み取りをインターセプトする必要があり、ソースファイルの代わりに、別のファイル、対応する修正が行われ、ソース管理に追加されていない一時ファイルをスリップします。 プロジェクトの起動元のフォルダーに応じて適用する必要がある修正のリストは、たとえば単純なxmlファイルで指定できます。



これを行うには、次のものが必要です。



新しいプロセス、フック付き32ビットおよび64ビットdll、バックグラウンドユーティリティによって実行される32ビットおよび64ビットexeの作成を監視し、フック付きの対応するdllを対応するビット深度のプロセスにロードするバックグラウンドユーティリティ。



バックグラウンドユーティリティは、ManagementEventWatcherクラスと、Win32_Processオブジェクトの種類と必要なプロセス名によるフィルタリングを使用した__InstanceOperationEventへの要求を使用して、WMIを通じてプロセスを監視します。 ____InstanceCreationEventイベントを受け取ることは、プロセスが作成されたことを意味し、その情報はEventArrivedEventArgs.NewEventから取得できます。 この場合、必要なのはProcessIdのみです。

processWatcher.Query.QueryString = @"SELECT * FROM __InstanceOperationEvent WITHIN 1" + "WHERE TargetInstance ISA 'Win32_Process' AND (" + string.Join(" OR ", processNames.Select(x => "TargetInstance.Name = '" + x + ".exe'")) + ")"; processWatcher.EventArrived += (sender, e) => { if (e.NewEvent.ClassPath.ClassName == "__InstanceCreationEvent") { var processId = (uint)((ManagementBaseObject)e.NewEvent["TargetInstance"]) .Properties["ProcessId"].Value; // ... Do smth useful } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DLLを外部プロセスにロードするアルゴリズムは標準です-外部プロセスでは、VirtualAllocExを介してメモリがdllへのパスの下に割り当てられ、LoadLibraryアドレスをCreateRemoteThreadに渡すことでストリームが作成されます。 フック初期化コードがDllMainにある場合、追加のアクションは必要ありません。 ただし、バックグラウンドユーティリティは、32ビットプロセスと64ビットプロセスの両方に同時にdllを個別に実装することはできません。 理論的には、64ビットプロセスからCreateRemoteThreadを呼び出すと、もちろん32ビットプロセスでスレッドを作成できますが、この場合、LoadLibraryはスレッドの関数として使用されます。 そして、最も簡単な方法では、GetProcAddressを使用して、現在のプロセスと同じビット深度のアドレスのみを取得できます。 Kernel32.dllのベースアドレスは固定されているため、同じビット容量の異なるプロセスの場合、関数のアドレスは同じです。 もちろん理論的には、PEヘッダーを手動で解析し、実装に追加のプロセスを使用することはできませんが、これはより複雑です。



もちろん、CreateFileW関数をインターセプトする必要があります。 最初はすべてのコードを完全にC＃で記述しましたが、実際にはこのような基本的な機能をインターセプトすると、マネージコードがたとえばプロセスによって読み込まれたサードパーティライブラリによってDllMainから呼び出されたときに、ローダーロックなどでエラーが発生します。 したがって、Cネイティブdllで処理する必要のあるフックとフィルター呼び出しをインストールする必要がありました。Cネイティブdllは、.configファイルに対してCreateFileWが呼び出された場合にのみマネージdllを読み込み、そこからマネージコードを呼び出します。 フックをインストールするには、 実績のあるサードパーティのライブラリMinHookを使用しました。インターネットには多くの情報があり、その説明については詳しく説明しません。 「Cですべてを完全に実行し、.netアセンブリの束を作成しない方が簡単ではなかった」という質問を誰かが尋ねるかもしれませんが、たぶん退屈です。



フィルタリングロジックは、ファイルが存在すること、ディレクトリではなくファイルであること、名前にweb.configが含まれていること、windows \ microsoft.net \ ...フォルダーにないことを確認する必要があります（システム構成には関心がありません）。 これらのすべての条件が満たされた場合、インターセプターによって元のシステム関数CreateFileWへの呼び出しから受信したHANDLEと、このHANDLEの内容を読み取るマネージハンドラーへのすべてのCreateFileWパラメーターを転送します。 簡単にするために、元のHANDLEを使用して再帰を防ぐことをお勧めします。これにより、同じフックが機能するため、File.ReadAllTextで同じファイルを読み取ることになります。 さらに、受信したコンテンツでは、必要なすべての行が置き換えられ、変更されたコンテンツは、名前が上記のフィルター基準を満たさない一時ファイルに書き込まれます（繰り返しになりません）。 web.configを開いたときと同じパラメーターでこの一時ファイルに対してCreateFileWを呼び出し、CreateFileWインターセプターから受信したHANDLEを返します。 元のハンドルは不要になったため、閉じる必要があります。







フックを持つネイティブdllは、LoadLibraryおよびGetProcAddressを介してマネージdllからハンドラーを呼び出します。 これを行うには、静的メソッドを通常のdll関数としてエクスポートする必要があります。 これは、ildasmで逆アセンブルし、ilコードのメソッドに特別なオプションを追加し、それをdllにアセンブルすることにより、少しシャーマニスティックな方法で行われます。 これについてはインターネットでも多くの記事がありますが、繰り返しはしませんが、「。vtentry」を検索することで簡単に見つけることができます。 ソースコードには、この方法でアセンブリを処理する簡単なユーティリティが含まれています。



IISExpressに加えて、同様の問題はwcfsvchostを介して起動されたwcfサービスにも関連しています。 確かに、この場合、変換の使用は正常に機能しますが、すべてが一貫しているため、変換で余分なファイルを複製せず、Configuration Managerで何も切り替えないように、この場合も考慮します。 いくつかの違いがあります-wcfsvchostはプロセスの開始時にすぐに構成を読み取り、WMIイベントの到着が遅すぎ、必要以上にフックが設定されます。 ただし、構成ファイルへのパスはコマンドライン経由で渡されるため、親プロセスに埋め込み、CreateProcessWをインターセプトする必要があります。



この場合の親プロセスはdevenv.exe、つまり Visual Studio この場合、初期システム関数CreateProcessWを呼び出す前に、マネージハンドラーで、プロセスが作成されるパラメーターの文字列と、修正された文字列が書き込まれる配列のアドレスを渡します。 ハンドラーでは、CommandLineToArgvWを呼び出すことで行がパラメーターに分割され、構成ファイルへのパスがそれらの間で決定され、修正された内容の一時ファイルが同じ方法で作成され、パラメーターのパスがそれに置き換えられます。







→ 記事のコード（完璧主義者にresしないでください-これは、エラー処理がなく、多くの仮定がある、急ぎで作られた最小限の作業バージョンです）