2011年5月2日月曜日

Visual Studio 2008の「へぇ~」な機能

Windows VISTAや7では、システム関係のファイルの書き換えに関してちょっとした保護機能が追加されている。WINDOWSフォルダやProgram Filesフォルダは、ファイルを変更しようとするといくらadmin権限でも確認ダイアログが出てくるし、アプリケーションでProgram Files以下に自分用の設定ファイルを保存するような(お行儀の悪い)アプリケーションでは、ファイルの保存先をコッソリとすげ替えさせられている。
特にUAC関連では叩かれることの多いMSだけれども、今回はその件をとやかく言うつもりはない。

今回、Visual Studioを使ってちょっとしたインストーラを作っていて気づいたことがありました。インストーラをデバッグ実行してもデバッグできなかった。理由は上のとおりで、Visual Studioから起動されるプロセスはVisual Studio自体のユーザー特権で実行されるから、Program Filesへの書き込みが禁止されているという訳だった。これまでは、ほとんどの開発をXPでやっていたから気づかなかったし、またReleaseビルドのときは親インストーラである”setup.exe"からの子プロセスとして実行されるインストーラだったので、特権レベルが"インストーラ"レベルに昇格されていて問題なく動いていた。が、開発環境を7で、Visual Studioから直接起動するとこの特権問題が露見した、という具合だったようです。

で、回避策として、Debugフォルダにあるデバッグ対象のインストーラ.exe自体を、エクスプローラ上からプロパティ変更して「管理者として実行する」に変更してみた。すると・・・、

Visual Studioはデバッグセッション開始時に、デバッグ対象.exeが「管理者として実行する」ことを要求していることを自動的に検知してダイアログを表示し、デバッグ処理を継続させるとVisual Studio自体が「管理者」権限で再起動した。

残念ながらそのままデバッグは開始しなかったけれど、この段階ではもうVisual Studioは管理者で実行されているので、再度F5でデバッグを開始すると難なくデバッグプロセスが開始され、以降ステップ実行やら変数インスペクションができた。もちろんインストーラとしてProgram Filesフォルダへのアクセスも自由にできている。

なかなか気が利いている、と思った。
しかし、起動している子プロセス(というかexeファイル)が管理者権限での実行を要求している、ということはどうやって検知しているのだろう?

0 件のコメント:

コメントを投稿