asp.net - 複数のインスタンスと web.config を持つ単一の ASP.net サイト

Question

IIS サーバーで実行されている従来の ASP.net を利用したサイトがあり、このサイトは中央チームによって開発され、複数の顧客によって使用されています。ただし、各顧客には、サイトの aspx ファイルと web.config ファイルの独自のコピーがあります。善意のサポートエンジニアがソース aspx ファイルのコピーに加えた変更が中央ソースに折り返されず、コードベースが分岐しているため、これが問題を引き起こしています。現在のフォルダー構造は次のようになります: OurApp/Source aspx & default web.config
Customer1/Source aspx & web.config
Customer2/Source aspx & web.config
Customer3/Source aspx & web.config
Customer4/Source aspx & web.config
. ..

これは、カスタマイズされた web.config ファイルだけを持つ各顧客と、共通のソースファイルセットを共有するすべての顧客に変更したいものです。次のようなもの: OurApp/Source aspx & default web.config
Customer1/web.config
Customer2/web.config
Customer3/web.config
Customer4/web.config
...

だから私の質問は、これをどのように設定するのですか? 私は通常、自宅で php と apache を使用しているため、ASP.net と IIS は初めてですが、職場では ASP.net と ISS を使用しています。

ソース管理が使用されており、サポートエンジニアを再教育するつもりですが、ソース aspx ファイルの複数のコピーを避ける方法はありますか? そんな重複は嫌だ！

score 6 · Accepted Answer

単一のアプリインスタンスに行き詰まっている場合は、単一の web.config でカスタム ConfigurationSection を使用した後、目的を達成できます。基本については、次を参照してください。

XML の例は次のとおりです。

<YourCustomConfigSection>
   <Customers>
     <Customer Name="Customer1" SomeSetting="A" Another="1" />
     <Customer Name="Customer2" SomeSetting="B" Another="2" />
     <Customer Name="Customer3" SomeSetting="C" Another="3" />
   </Customers>
</YourCustomConfigSection>

次に、ConfigSection プロパティで、Name、SomeSetting、および Another を公開します。プロパティがアクセスまたは設定されると、条件 (リクエストドメインまたは顧客を一意に識別するその他のもの) を使用して、どちらを使用するかを決定します。

適切に実装すれば、アプリ開発者は舞台裏で何が起こっているかを意識する必要がなくなります。CustomSettings.Settings.SomeSetting を使用するだけで、どの顧客がアプリにアクセスしているかは気にしません。

score 2 · Accepted Answer

面倒に思えるかもしれませんが、重複は実際には良いことです。ここでの問題は、システムのセットアップ方法ではなく、プロセスにあります。

サイトを別々に保つことは、実際には良いことです。「複製」のように見えますが、実際にはそうではありません。別れです。サポートエンジニアが製品コードを変更することは、積極的にやめさせるべきです。

どこにでも展開したら、プロセスを変更して変更することを検討する必要があります。これにより、長期的にはすべてがずっと簡単になります。

実際にあなたの質問に答えるには、答えはノーです。それはできません。その理由は、web.config はユーザーレベルの設定を保存するようには設計されておらず、アプリケーションインスタンスごとの設定を保存するように設計されているためです。あなたの場合、ユーザーごとにアプリケーションインスタンスが必要です。これは、個別の構成ファイルを意味します。

システムが機能するためには、使用する構成ファイルをアプリケーションに事前に通知できる必要がありますが、これはユーザーからの何らかの入力なしでは不可能です。

score 1 · Accepted Answer

外部ソース管理アプリケーションを使用し、必要に応じて更新を展開し続けます。

いずれにせよ、ライブサイトをサポートエンジニアがリアルタイムで更新できるようにすることは、あまり良い考えではありません。

score 0 · Accepted Answer

私が話すときにこれを実装しています。

メインのweb.configには、インストールごとに1つのアイテムがあります。これは、クライアントごとに作成したカスタム構成ファイル（および、カスタムマスターページ、css、イメージなど）を示しています。

WebConfigurationManager.OpenWebConfigurationを使用して、サブディレクトリで新しいWeb構成を開きます。System.Web.HttpContext.Current.Request.Url.OriginalStringを使用して、どちらを使用するかを決定し、私を呼び出したuRLを決定します。そのURLに基づいて、使用するweb.configがわかります。

その時点から、クライアントはすべて同じコードベースを使用します。彼らは独自のデータベースも持っています。

更新時に30〜40のインストールを更新しなければならないという考えは、私を怖がらせます。30〜40のコードベースをサポートしたくないので、マスターページ、css、およびイメージ以外のカスタマイズはありません。

適切なwebconfigに切り替える方法を知っているカスタムクラスlibを作成し、すべての設定で作成したカスタムセクションを読みました。

私が今抱えている唯一の問題は、FormsAuthenticationCookieです。私もそれを切り替えることができる必要があります。残念ながら、名前のプロパティは読み取り専用です

score 0 · Accepted Answer

回答ありがとうございます。それらを読んで考えた後、今は複数のインスタンスをそのままにしておき、最初に更新プロセスを改善しようと思います。次に、データベース層にユーザー構成情報を持つ新しいバージョンのアプリケーションを開発し、誰かが提案したように、要求ドメインまたは URL に基づいてユーザーを選択します。そうすれば、複数の異なるクライアント構成をきれいにサポートする単一のアプリケーションインスタンスを持つことができます。

ほとんどのクライアント構成データは実際にはプレゼンテーションまたはデータソースに関連しているため、複雑なことは何もありません。最終的に複数のアプリケーションインスタンスができたのは、元のプログラマーが複数の顧客を期待しておらず、そのための設計を行っていなかったことが主な理由だと思います。そのため、誰かが後でやって来て 2 番目の顧客を追加したときに、アプリケーションを複製しただけで、インスタンスごとに無駄が生じました。オリジナルとほぼ99.99%同一です。

score 0 · Accepted Answer

Web 構成の実際の内容と顧客ごとに異なる設定に応じて、単一の Web 構成を使用し、他の顧客固有の構成オプションをデータベースまたはその他のカスタム xml/テキストファイルに保存することを選択できます。web.config の特定の顧客設定が IIS の動作に影響を与える必要がなく、IIS を使用して値を保存するだけである限り、このソリューションはうまく機能する可能性があります。

score 0 · Accepted Answer

私の理解が正しければ、web.config だけが異なる複数の展開 (クライアントごとに 1 つ) があるようですね。

最初に、あなたの固有の状況はわかりませんが、一般的には別々のインストールを続けることをお勧めします. 通常は、はるかに柔軟に対応できます。私の頭の上から: カスタマイズしたり、異なるバージョンを実行する異なるクライアントを使用したりする予定はありますか? よろしいですか？ここで柔軟性を維持する最も簡単な方法は、個別のインストールを続けることです。

私の意見では、プラクティスが適切に調整されていれば、それはまったく醜いことではありません。あなたが言及したいくつかのことに基づいて、あなたはその分野で問題を抱えています-明らかに、ソース管理のバイイン/トレーニングの問題の可能性があります。しかし、あなたはそれを知っています。また、展開手順なども詳しく見ていきます。その分野でさらに問題が発生する可能性があると感じていますが、まったく不快ではありません.

とはいえ、これを進めたいとしましょう。

すべてのクライアントが単一の共通データベースを共有しているかどうかはわかりませんでしたが、私はそうは考えていません。なぜなら、そのようなタイプのシステムを設計することは、余分な複雑さ (あらゆる規模のシステムで深刻になる可能性があります) に値しないことが多いためです。それらを別々に保つために。

つまり、接続文字列をどこかに保存しているということです。通常、それは web.config になります...だから、それは私たちの計画を破るようです。

実際、この状況の見かけの優雅さは、ほとんどの場合、それがもたらす課題によって大幅に相殺されます。十分に考えた場合、接続文字列をインテリジェントに管理する別のデータベースを導入するか、すべてのログイン情報を web.config に直接保持することを検討することで、これを回避する方法を見つけることができます (これは可能ですが... 理想的ではありません)。、しかし、私の直感は、いつかあなたが今やっている方法に戻ることになるので、その仕事は無駄になるだろうと言っています.

また、本番環境でコードを直接変更することは、ここでは明らかにベストプラクティスではありません。しかし、モノリシックな共有プラットフォームを使用している場合、トラフィック量に関係なく、これは決して起こり得ません。思考の糧。

何か不足している場合はお知らせください。

asp.net - 複数のインスタンスと web.config を持つ単一の ASP.net サイト

7 に答える 7

Related

Reference