アプリケーション構成ファイルとは?

単純には、INI 形式ファイルを少し便利にしたものだと考えてもらえればよいのではないだろうか?
それってレジストリじゃないの? という話もあるが、レジストリはそれなりに多彩な情報を階層構造をもって保持できる場所として使えるし、設定情報を保存する場所として使うことができるが、格納された情報そのものはユーザによって直接編集されることを期待しないで、アプリケーションを通して編集されるものである。
それに対してアプリケーション構成ファイルは、もう少し INI ファイル寄りなテキストベースの設定ファイルとして XML 形式をとっており、ユーザが閲覧したり直接編集したりすることができる。とはいえ、通常はインストール先に保存されるものなので管理者が設定するような項目を保持し、個々のユーザの設定を保持する場所ではない。INI 形式ファイル時代は、アプリケーションのインストール先に設定を保持した INI 形式ファイルを作ることが多かったが、現在はアプリケーションは管理者によって Program Files 以下に配置され、個々のユーザは Program Files 以下に書き込み権限がなく、ユーザ別の設定ファイル等は個々のユーザの Profile 以下に配置されるようにするのがベターな選択である。*1

構成ファイルとは?

構成ファイルとは、System.Configuration 名前空間に用意された各クラス*2を利用してアクセスする読み取り専用の情報セットのこと、となっている。構成ファイルには

  • マシン構成ファイル
  • アプリケーション構成ファイル
  • セキュリティ構成ファイル

の3種類があり、ここではセキュリティ構成ファイルについては割愛する。そして、アプリケーションが直接利用するのは、当然ながらアプリケーション構成ファイルであるが、実際のところマシン構成ファイルについても少し触れておかなければならない。
INI 形式ファイルは、そのファイルに記載されている情報がすべてではあるが、*3アプリケーション構成ファイルは、マシン構成ファイルに記載されている内容を継承することができるようになっている。つまり、複数のアプリケーション間で共通する設定を、マシン構成ファイルを通して共有したり管理したりできるようになっている。.NET Framework 開発者ガイドでは、結構手軽にマシン構成ファイルに手を入れちゃってもよいような感じの書き方になってたりするんだが、昔 Windows ディレクトリに INI ファイルを作成したり、WIN.INI ファイルなどに独自の構成セクションを作りこむアプリケーションが嫌われていたように、マシン構成ファイルをどんどん変更しちゃうようなアプリケーションは絶対に嫌われるだろう。マシン構成ファイルを利用して複数アプリケーションで設定を共有するというのは、アプリケーションが提供する機能ではなく、システム管理者が選択的かつ自発的に設定ファイルを編集して実行すべき項目となるべきだろうと思う。

*1:まあ、個人やファミリーで使われているような場合は、従来形式でなんら問題ないんだけどね

*2:.NET Framework Guide では、このような名前空間やクラス群、メソッドを総称して API と呼んでいるが、まだまだ API というとアンマネージな世界の Win32 API を思い浮かべる人が多いため API とは記述しないでおこう...私もそうだし

*3:Windows NT/2000/XP ではレジストリマッピングすることで、ユーザ単位で動的に内容を変更できたりするが、それはそれでレジストリへの移行のためのレジストリ側の機能として捕らえてください