クラス ライブラリの構成ファイルで接続文字列を指定し、後で ASP.NET Web アプリケーションで使用するときにこれを変更するにはどうすればよいでしょうか。
クラス ライブラリは、構成ファイル (Settings.settings/app.config) で指定された接続文字列に基づいてデータベースに接続するデータセットを持つデータ アクセス レイヤーです。
このクラス ライブラリは、ユーザーがデータを入力する Web アプリケーションで使用され、クラス ライブラリで公開されている DAL クラスとメソッドを使用してデータベースに書き込まれます。
ここで、このアプリケーションを開発環境からテスト環境に移行し、その後本番環境に移行したいと考えています。私が直面している問題は、テストに移行した後、テスト中のアプリがまだ開発データベースに接続していることです。<class library>.dll.configファイルに記載されている接続文字列を変更しましたが、影響はないようです。
誰かがこれを達成する正しい方法を説明できますか? 助けてくれてありがとう。乾杯。
.config ファイルでは、名前はメインの実行アセンブリと一致する必要があります。たとえば、あなたのような状況がありました.dll.configファイルに設定を入れるにはクラスライブラリが必要でした。それを参照することはできましたが、実際のアプリケーションは .exe.config を予期していたため、構成ファイルを読み取ることができませんでした。.dll.config の名前を .exe.config に変更すると、問題が修正されました。
あなたの場合、接続文字列を .dll.config から web.config に移行すると、問題が解決するはずです!
幸運を！
ジョシュアは部分的に正しいです...後世のために、私は何度か同じ問題を抱えているので、この回答にもう少し追加したいと思います。まず、それらのアーキテクチャを検討する必要があります。展開に基づいて、ASP.NET の .config ファイルで発生する可能性のある問題がいくつかあります。
アーキテクチャ上の影響を考慮すると、次のようになります。
単一層 (1 サーバー): シンプルな Web アプリケーションで、サイトの Web.config ファイルへの参照を利用して問題を解決できる場合があります。これは、単一層のアプリケーションにとって優れたソリューションです。.exe ファイルとして利用される Windows アプリケーションの場合、App.config も機能します。
多層 (複数のサーバー): ここでは、境界を越えて .config ファイルを初めて操作したとき、少し複雑になりました。config 構造の階層を覚えておいてください ( .Config 構造に関する MSDN の記事 )。) - 適切な ASP.NET フォルダーのルートに machine.config があります。これらは各物理サーバーにあります。これらはサイトの Web.config (または App.config) によってオーバーライドされ、サブフォルダーの .config ファイルによってオーバーライドされます。複数の .config ファイルがある場合は、メソッドの 1 つを使用して、使用する特定の .config のファイル パスを渡すことができます。さらに重要なことに、これらのファイルにはそれぞれ接続情報が含まれている場合があります。ASP.NET の machine.config は、フレームワークの一部を保持しています...したがって、少なくともこれが「継承」チェーンであるという事実に注意する必要があります。次に、デプロイ後に Web.config ファイルを変更すると、アプリケーションに再起動が指示されます。これにより、状態が失われます (サイトにアクティブなユーザーがいる場合は良くありません)。これを回避する方法は、別の .config ファイルを保持することです (例: connections. config) を作成し、そのファイルへの参照を Web.config に入れます。これにより、アプリケーションを再起動せずに接続情報 (パスワードなど) を変更できます。詳細情報へのリンクは次のとおりです。MSDN: 構成ファイルの操作. この記事では、通常のサーバー/IIS で展開されたアプリケーションで注意する必要があるすべての詳細について説明します。.config ファイルは主にアプリケーション用であり、ライブラリ用ではないことに注意してください。複数の層がある場合は、何らかの通信/メッセージング層 (WCF など) を使用している可能性があります。これは、独自の Web.config を持つ/許可します。そこに接続文字列を保持する (必要に応じて暗号化する) ことができますが、管理しやすいように、Web.config によって参照される 2 番目のファイルに接続文字列を配置することをお勧めします。最後のポイントとして、クラウドを検討する場合、.config ファイルはアプリケーションの展開用にラップされます。これにより、「再起動や再展開が不要」という点で、.config ファイルが提供するすべての利点が事実上なくなります。Azure のデプロイは、メンテナンスの悪夢から身を守るために、この記事を検討する必要があります。 Bill Lodin ブログ - Azul / Cloud の構成ファイル。この記事のもう 1 つのポイントは、展開に応じてプログラムで構成を選択する方法の優れた例です。クラウドの内外に展開する柔軟性を追加したい場合は、必ずチェックしてください。
これらのポイントが皆さんの時間と頭痛の種を救うことを願っています. これらの問題に対処するために数日間のプログラミング時間を失ったことはわかっています...そして、アプリが接続オブジェクトを「実装」していない理由をすべて 1 か所で見つけるのは困難でした。願わくば、これが私と同じ運命から皆さんを救ってくれることを願っています。