11

私たちの製品は ASP.Net Web アプリケーションです。現在、Visual Studio で Web サイト プロジェクトを使用していますが、かなり前から Web アプリケーション プロジェクトの使用を検討しています。展開プロセスを改善できるように、現在それらを調査しています。

異なるクライアント間で共有および共通のベース Web サイトがあり、それをクライアント Web サイト プロジェクトのクライアント固有の機能で拡張します。クライアント プロジェクトはベースを拡張するため、そのコンテンツに依存します。完全な製品を構築するには、まずベース Web サイトを展開し、次にクライアント プロジェクトのコンテンツをオーバーレイします。

Visual Studio での Web アプリケーション プロジェクトへの変換を検討するにあたり、ベース プロジェクトを作成し、次にクライアント プロジェクトを作成してベースへの参照を設定できるようにしたいと考えていました。この構造は正常に機能しているように見えますが、MSDeploy を使用してクライアント プロジェクトからアプリケーションをデプロイしようとすると、ベース Web サイトからの dll のみが発行されます。コンパイルされたコードを参照すると便利な場合もありますが、クライアント アプリケーションが機能するために必要なソースである画像、js ページ、htm などの項目もあります。ベース Web サイトからコンパイルされたコード以上のものが必要です。

以上のことから、ここでいくつかのオプションを考えることができます。

  1. 2 つのステップでデプロイを続行します。最初にベース Web サイト、次にクライアント Web サイトで完全な製品を構築します。
  2. ベース プロジェクトから必要なソース ファイルをコピーするようにデプロイ プロセスを変更します。
  3. モデルを再構築して、このベースとクライアントの関係を別の方法でサポートします。これがどのように機能するかはよくわかりませんが、実行可能な選択肢が最も少ないでしょう。
  4. ??

私が見逃している別のオプションはありますか？プロジェクトの設定方法に何か問題がありますか? コンパイルされたコードを共有する以外に、Web アプリケーションが別の Web アプリケーションを参照できるようにすることはありますか? その場合、共有クラス ライブラリを使用しないのはなぜでしょうか。または、MS Deploy プロセスで何か不足している可能性がありますか?

何かが足りないような気がするので、ここで提案を受け付けています。私たちの Web アプリケーションのモデルがあまりにもユニークだとは思いません。

更新: デュアル デプロイ プロセスは機能しますが、少しぎこちなく感じます。他の入力はありますか？

4

4 に答える 4

1

アセンブリWebResourceを使用することにより、CSS / JS /その他のファイルをコード（ベースプロジェクトDLL）とともに参照として追加できます。

正しければ、このWebResourceをベースプロジェクトに追加してから、以下のリンクにアクセスしてください。

http://support.microsoft.com/kb/910442

このように、ほとんどのサードパーティツールはCSSファイルとJSファイルにアクセスします。

これを試して。それがお役に立てば幸いです。

于 2013-01-31T07:24:36.627 に答える
0

プロジェクト間で何を共有しているか、どのように共有しているかを注意深く分析します。

コンパイルされたコードの場合、正しい方法は、それらのクラスを独自の名前空間とアセンブリに抽出し、プロジェクト間で DLL を共有することです。リファクタリング中は、OO と SOLID の原則に従っていることを確認してください。

共有するのがコンテンツ (js、htm、画像、css) である場合、いくつかのオプションがあります。コンテンツ用に別の仮想ディレクトリを作成し、絶対 URL でコンテンツを参照できます。これは、後で IIS でプロジェクトを独自の Web サイトに分離する必要が生じた場合に、コンテンツの URL を変更する必要がないため、役立ちます。いわゆるベース Web サイトにすべてのコンテンツを配置し、ベース Web サイトに対する相対パスを使用して他のプロジェクトのコンテンツを参照することもできます。

一方、共有するのが ASP.NET ユーザー コントロールまたは ASP.NET MVC ビューである場合は、プロジェクトごとに個別の項目を作成することをお勧めします。これは、必ずしもそのパスに個別の物理ファイルがあることを意味するわけではありません。参照リンクのみである項目を Visual Studio の .NET プロジェクトに追加することもできます。

展開プロセスに関しては、Web サイト プロジェクト自体に問題はないと思います。Web サイト プロジェクトには、Web アプリケーション プロジェクトとは異なる目的があります。主な目的は、コードを配置するたびにクラスをコンパイルする必要がないことです (正しいアプリケーション フォルダーにある場合)。Web サイト プロジェクトでは、2 段階の展開プロセスに固執することをお勧めします。

また、IIS で作成された Web サイト (仮想ディレクトリ) を確認し、意味がある場合はそれらをネストすることを検討します。また、アプリケーション プール (個別か共有かに関係なく) を見直しても害はありません。

最後に、これは古い質問です。成功した戦略をすでに実装している場合は、共有してください。

于 2013-01-30T04:17:47.380 に答える
0

私があなたの質問を正しく理解していれば、コンパイルされていないアイテム (htm、JS、画像など) も公開したいと考えています。

そのため、[ソリューション エクスプローラー] タブの各ファイルには独自のプロパティ (F4 キーでアクセス) があり、ビルド アクションを選択できます (たとえば、コンパイル -> 該当する場合は DLL に項目を挿入し、コンテンツ -> ファイルをコピーします)"そのまま」出力ディレクトリへ)。

オプション「出力ディレクトリにコピー」を「新しい場合はコピー」に設定したビルドアクション「コンテンツ」が、あなたが探している解決策かもしれません。

于 2012-11-12T20:05:15.247 に答える
0

サイトはクライアント間でどのように「共有」されていますか? 各クライアントは最終的に異なるサイト (IP アドレスなど) を取得しますか? それとも、同じサイトにログインしても異なる機能を取得しますか? すべての機能を単一のプロジェクトに追加してから、設定を介して機能を有効/無効にすることを検討することをお勧めします。

于 2012-03-21T17:22:30.643 に答える