Visual Studioの開発者固有のapp.config / web.configファイル

Question 1

いくつかの.NETプロジェクトがあり、特定の設定を構成ファイルに保存しています。

これで、各開発者は少し異なる独自の構成ファイルを持ちます（ローカルデータベースに接続するための異なる接続文字列、異なるWCFエンドポイントなど）。

現時点では、app / web.configファイルをチェックアウトして、ニーズに合わせて変更する傾向があります。

TFSから最新バージョンを取得するときに、誰かが自分の設定をチェックインしたり、カスタム構成を緩めることが時々あるため、これは多くの問題につながります。

このような状況にどう対処しますか？それとも、この問題はまったくありませんか？

Question 2

私たちは、このページの既存の回答のいくつかを組み合わせたシステムを使用しており、さらにScott Hanselmanによるこの提案を利用しています。

つまり、ここで行った他の回答で示唆されているように、共通のapp.config / web.configを設定し、特定の設定のほとんどを個々のファイルに含めることでした。たとえば、SMTP設定の場合、app.configには

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

このファイルはソース管理下にあります。ただし、次のような個別のファイルはそうではありません。

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

話はこれで終わりではありません。新しい開発者、またはフレッシュソースインストールについてはどうですか？構成の大部分はソース管理ではなくなったため、必要なすべての.configファイルを手動で作成するのは面倒です。私は少なくとも箱から出してすぐにコンパイルできるソースがあることを好みます。

したがって、.config.defaultファイルという名前のバージョンの.configファイルをソース管理に保持します。したがって、新しいソースツリーは次のようになります。

代替テキスト

それでも、Visual Studioにとっては意味のないテキストファイルであるため、実際には開発者にとっては何の用途もありません。したがって、バッチファイルはcopy_default_config.bat、.config.defaultファイルから.configファイルの初期セットを作成します。

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

スクリプトは安全に再実行可能であり、すでに.configファイルを持っている開発者はそれらを上書きしません。したがって、このバッチファイルをビルド前のイベントとして実行することができます。.defaultファイル内の値は、新規インストールでは正確ではない可能性がありますが、妥当な出発点です。

最終的には、各開発者は最終的には次のような設定ファイルのフォルダーになります。

代替テキスト

少し入り組んでいるように見えるかもしれませんが、開発者が互いにつま先を踏む煩わしさよりも間違いなく望ましいです。

Question 3

Web.configで他のファイルのソースを使用する

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

web.configをバージョン管理に維持し、ConnectionStrings.configに対しては行わないでください。これで、すべての開発者が接続文字列用に1つのファイルを持っています。

これは、ローカルに依存するすべての設定に対して行うことができます。

Question 4

ここでweb.configファイルとVisual Studio 2010のソリューション：

1）Webアプリケーションの.csprojファイルを手動で編集して、次のAfterBuildようにターゲットを追加します。

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

このターゲットは、現在ログインしている開発者に対応するWeb.configファイル（つまり$(USERNAME)変数）を、1）で作成した対応するファイルで変換します。ローカルWeb.configがソース管理されている場合でも、ビルドごとにコンテンツが（再起動を回避するために）変更された場合にのみ、ローカルWeb.configが置き換えOverwriteReadOnlyFilesられます。そのため、がTrueに設定されています。この点は実際には議論の余地があります。

2）Web.[developer windows login].configプロジェクトの開発者ごとに名前が付けられたファイルを作成します。（たとえば、次のスクリーンショットでは、smoとsmo2という名前の2人の開発者がいます）：

ここに画像の説明を入力してください

これらのファイル（開発者ごとに1つ）は、ソース管理することができます。個別にチェックアウトできるようにするため、メインのWeb.configに依存しているとマークしないでください。

このファイルはそれぞれ、メインのWeb.Configファイルに適用する変換を表しています。変換構文については、ここで説明します。WebアプリケーションプロジェクトのデプロイメントのためのWeb.config変換構文。Visual Studioに付属しているこのクールなXmlファイル変換タスクを再利用します。このタスクの目的は、ファイル全体を上書きするのではなく、Xml要素と属性をマージすることです。

たとえば、次のサンプルweb.[dev login].configは、残りのWeb.configファイルに関係なく、「MyDB」という名前の接続文字列を変更します。

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

さて、このソリューションは完璧ではありません：

ビルド後、開発者はローカルでソース管理システムとは異なるWeb.Configを持つ可能性があります
ソース管理システムから新しいWeb.Configを取得するときに、ローカル書き込みを強制する必要がある場合があります。
開発者はメインのweb.configをチェックアウト/チェックインしないでください。それは少数の人に予約されるべきです。

ただし、少なくとも、開発者ごとに一意のメインweb.configと1つの変換ファイルを維持するだけで済みます。

App.config（webではない）ファイルについても同様のアプローチをとることができますが、これ以上詳しく説明しませんでした。

Question 5

環境間のweb.configの違いを避けるために、machine.configを使用しています。

Question 6

ファイルを無視して、チェックインされないようにするのはどうですか？私は同様の問題に遭遇し、Subversionの無視リストにweb.configを追加しました。

ただし、TFSでは少し難しいです。その方法については、この投稿を参照してください。

Question 7

対処できる1つの方法は、トークン化されたシステムを用意し、rakeスクリプトを使用して値を変更することです。

より初歩的な方法は、web.config内のすべてのAppSettingsのAppSettings.configファイルへのリンクを持つことです（接続と同様）。

<appSettings configSource="_configs/AppSettings.config" />

次に、各開発者のフォルダーをサブフォルダー（つまり、/ _ configs / dave /）に入れます。次に、開発者が独自のコードで作業しているときに、サブフォルダーからリンクされたフォルダーのルートにコピーします。

（トークン化しない限り）これらのファイルへの変更を確実に伝達する必要があります。AppSettings.configファイルをソース管理の対象外にして、devsの個々のフォルダー（すべて）のみをチェックインすると、正しいフォルダーが強制的にコピーされます。

私はトークン化を好みますが、これが迅速な修正であることだけを意図している場合、立ち上げて実行するのは難しくなる可能性があります。

Question 8

ファイルを無視して、Commom_Web.ConfigとCommon_App.Configを作成します。これらの2つの名前を通常の名前に変更するビルドタスクで継続的インテグレーションビルドサーバーを使用して、ビルドサーバーがその仕事を行えるようにします。

Question 9

私たちは同じ問題を抱えており、私たちがしていることは

testserver / productionの値でweb.configをチェックインします
開発者はWindowsエクスプローラーに行き、ファイルの読み取り専用モードを変更します
環境に合わせて設定を編集します。
web.configへのチェックインは、デプロイメントの値が変更されたとき、または構成エントリが追加または削除されたときにのみ行われます。
これは、各開発者が変更する必要があるため、各構成エントリに十分な量のコメントが必要です。

Question 10

Visual Studioを使用していると仮定して、異なるソリューション構成を使用してみませんか？たとえば、Web.config.debugを使用するデバッグ構成と、Web.config.releaseを使用するリリース構成を使用できます。Web.config.debugは次のようになります

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config">

すべての個人開発者設定を取得するファイルStandard_Name_For_Config.configを使用しますが、Web.config.releaseには常に本番環境設定があります。一部のソース管理フォルダーにデフォルト設定を保存して、そこから新しいユーザーにそれらを取得させることができます。