10

今、私は以前にSOでこの質問をさまざまな方法で見ましたが、驚くべきことにこの形式ではありません。

相互に通信する必要のある複数のWebサービス（プロジェクト）を使用したソリューションがあります。これらの各Webサービスを公開した後、データベースが異なる別のマシンに配置される可能性があります。他のすべてのWebサービスがどこにあるかを各Webサービスに伝えるために、開発中に単一の構成ファイルを維持したいと思います。

構成を公開した後、公開された各プロジェクトに存在することを期待したいと思います。また、公開後に構成ファイルを編集できるようにしたいと思います。これにより、特定のWebサービスをすばやく移行してから、他のWebサービスのすべての構成ファイルを編集できます。

私はデータベースでこれを行いたくありません。設定ファイルの場合、それ自体がデータベースへの接続設定も保持する必要があります。

私は次のアイデア/考え/質問に出くわしました：

  • 他のプロジェクトから参照されている「common」というdllプロジェクトがあります。その1つにshared.configを指定し、を実行してshared.configを読み取るために使用できるクラスをそのプロジェクトに構築しましょうSystem.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config")。shared.configがDLLと一緒に公開されることを確認する必要があります。

プロジェクト固有の設定だけを持つ各プロジェクト内にweb.configを保持できるので、このソリューションを好みます。そして、共有設定を持つshared.configを用意します。しかし、私はSOについて読んだのですが、これは軽視すべきではなく、ファイルアクセスの問題などの望ましくない副作用が発生する可能性があります。これが私の場合にも当てはまるのだろうかと思いますが。また、Visual StudioがDLLプロジェクトのapp.configをすぐにサポートしているとは思わないので、これを実際に実現する方法について、ここで助けを求めたいと思います。

  • また、ソリューションアイテムにshared.configファイルを作成することも考えました。次に、各プロジェクト内でそのファイルをリンクします。そして、各プロジェクトのWeb.configに、次を追加<appSettings configSource="shared.config" />します。そのプロジェクト内のリンクされたファイルを指します。

これを行わない理由はわかりませんが、最初の実装は失敗しました。（少なくとも開発中は）c＃はリンクされたshared.configファイルを見つけることができないようです。リンクされたファイルを作成した後、ファイルのリンクが即座に実行されたり維持されたりすることはないと思いますが、ファイルは公開時にのみプロジェクトにコピーされます。したがって、開発中にファイルが欠落したままになります。これは正しいです？

4

3 に答える 3

6

構成ファイルはアプリ固有です。これは、構成ファイルをクラス ライブラリに追加できることを意味しますが、そのファイルはライブラリを参照するアプリ (Windows サービス、Web サービスなど) によって使用されます。

external についても同じことですconfigSource。これはアプリ固有のものでもあり、それを使用するプロジェクトに含める必要があります。したがって、ソリューションが 2 つのプロジェクトで構成されている場合は、2 つの構成ファイルが必要です。プロジェクトごとに 1 つ。

Windows ベースのアプリケーション (サービス、winforms) の場合、構成ファイルの予期されるフォルダーはbinディレクトリですが、Web ベースのプロジェクトの場合、これは仮想ディレクトリのルート フォルダーであるディレクトリになります。

つまり、共有構成ファイルを使用する方が簡単な解決策に見えます (また、各プロジェクトのクラス ライブラリから app.config をコピーする必要はありません)。手順は次のとおりです。

  • ソリューション フォルダーを作成します。
  • それに設定ファイルを追加します。
  • ファイルを必要とする各プロジェクトの参照としてファイルを追加します。プロジェクトを右クリックして既存のアイテムを追加- >ファイルを選択してリンクとして追加
  • 常にコピー オプションを使用してコピー オプション (ファイルのプロパティ) を設定することにより、ファイルが常にコピーされるようにします。

この時点で、ソリューションをコンパイルするたびに、構成ファイルをプロジェクト ディレクトリにデプロイする必要があります。

編集：

  • Web アプリ内の構成ファイルのビンを調べることは避けたいと思います。規則では、ファイルはルートにある必要があるため、最初のオプションは避けます。
  • リンクされたファイルは、プロジェクトをビルドした後、最終的にビンに入れられます。ファイルをインポートするための同じ手順を試してみてください。ただし、今回はファイルを (リンクとしてではなく) 追加するだけで、サイトのルートにコンテンツとして展開されるため、いつでも利用できます。
于 2013-03-19T10:06:07.527 に答える
0

これは実際に私を少し夢中にさせました。最終的に次のように修正しました。

  • dll プロジェクト 'common' に Shared.config ファイルを作成し、その内容は通常の web.config/app.config のように見えます。
  • ファイルを Content and Copy Always に設定して、プロジェクト共通を参照するすべてのプロジェクトに確実にコピーされるようにします。(ただし、構成ファイルは実際にはbinフォルダーに配置されます。
  • SharedConfiguration共通プロジェクト内にクラスを作成しました。本当にトリッキーな部分は、 Open MappedExeConfiguration() を使用しなければならず、実行可能ディレクトリへのパスを取得することでした (bin を含み、その前に file:// を付けません)。
  • 共有設定から設定にアクセスしたいときは、SharedConfiguration.instance.AppSettings.Settings["CubilisEntryPointUrl"].Value.

(この問題SharedConfiguration.instance.AppSettings["CubilisEntryPointUrl"]のため、直接使用することはできません)

.

public static class SharedConfiguration
{
    public static readonly Configuration instance = GetConfiguration("Shared.config");
    private static Configuration GetConfiguration(string configFileName)
    {
        ExeConfigurationFileMap exeConfigurationFileMap = new ExeConfigurationFileMap();
        Uri uri = new Uri(Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase));
        exeConfigurationFileMap.ExeConfigFilename = Path.Combine(uri.LocalPath, configFileName);
        return ConfigurationManager.OpenMappedExeConfiguration(exeConfigurationFileMap, ConfigurationUserLevel.None);
    }
}
于 2013-03-19T15:11:36.200 に答える
0

IIS でホスティングしている場合、ルート サイト レベルで単一の web.config ファイルを持つことが可能ですが、Giorgio は app.config ファイルがアプリ固有であるという点で正しいです。カスタムビルドステップを使用して、複数のプロジェクト間で構成ファイルのコピーを自動化することができるので、個人的にはそれを使用します.

于 2013-03-19T10:10:39.157 に答える