同じサーバー上の複数のWebアプリケーション間でbinフォルダーとdllおよびその他のリソースファイル（cssなど）を共有するためのベストプラクティスは何ですか？
共通コードを独自のアセンブリに分割しましたが、デプロイなどについて疑問に思っています。基本的に、すべての共通ファイルをWebサーバーの1つの場所に配置し、各Webアプリにその共通の参照を設定します。位置。
現在、別の場所からbinフォルダーを使用するようにAsp.netWebサイトに指示する方法がわかりません。
違いがあれば、これらはASP.NETMVCアプリケーションです。
助けてくれてありがとう。
mklink- http: //technet.microsoft.com/en-us/library/cc753194%28WS.10%29.aspx
また、ServerFaultでこの質問を参照してください-https : //serverfault.com/questions/7109/how-do-i-create-a-symbolic-link-in-windows
ベストプラクティスは、そうしないことをお勧めします。
それぞれのアプリケーションは異なります。そのように扱ってください。リソースを共有することにより、プロジェクト間に暗黙の依存関係が作成されます。共有リソースを変更すると、意図したかどうかに関係なく、すべてのリソースが変更されます。
本当にリソースを共有する必要がある場合は、ソース管理またはビルドのレベルで行ってください。運用サーバーにデプロイした後に依存関係を解消するよりも、そのレベルで依存関係を解消する方がはるかに簡単です。
Xanadont、共通ライブラリの共有などは問題ありませんが (これは本質的に nHibernate のようなオープン ソース プロジェクトが行うことです)、実稼働サーバー上の bin 共有フォルダーのレベルでこれを行うと、解決するよりも多くの問題が生じます。あなたが話している再利用の種類は、バイナリ バージョンがどこかに維持されているソース管理内の独立したプロジェクトである共有ライブラリを作成することによって最もよくアプローチされます。共有ライブラリを使用したいプロジェクトは、バイナリ依存関係を取得しますソリューション ソース ツリーの lib フォルダーにバイナリをコピーし、そのバイナリを参照することにより、共有ライブラリで。これにより、共有ライブラリへの直接的な依存関係による副作用を引き起こすことなく、共有ライブラリを維持および更新できます。また、ライブラリを使用するソリューションは、修正/更新を評価して、それらに依存するコードにどのように影響するか、およびアップグレードが必要かどうかを判断できます。価値があります。
Scottさん、あなたが言及しているのは、ビュー レイヤー(テンプレート) にバリエーションがある 1 つのアプリケーションであり、ビジネス ロジックにバリエーションがある 50 個のアプリケーションではありません。この種のアプリケーションの最善のアプローチは、マルチテナント (都市ごとに 1 つのデータベースもあると想定しているため) であり、URL を使用して、データベースにアクセスし、ビュー パスを解決できるコンテキストを定義します (説明が難しい)アプリケーション アーキテクチャをよく理解していなくても、より適切なアプローチを使用できます)。
URL に基づいてビューを変更するには、コンテキスト認識ビュー エンジンを実装します (これを行う方法の例については、http://www.coderjournal.com/2009/05/creating-your-first-mvc-viewengine/を参照してください)。 .
この種のアプローチでは、修正で更新する必要がある場所は 1 つだけですが、新しい一連のテンプレートを追加するだけで、別の都市の新しい「サイト」を簡単に作成できます (ルーティングの設定方法によって異なります)。 ) サイトで新しいドメインを指定します。デフォルトのテンプレートのセットがある場合、カスタマイズが存在しない場合、ビュー エンジンはこれらにフォールバックする可能性があるため、アプリケーションに新しいドメインを指定するだけで新しいサイトをセットアップできます。