3

これは VS 2008 と .Net 3.5 です。

パブリッシュの右クリック メニューに似たカスタム デプロイメント プロジェクト スクリプトを使用しますが、ファイルの名前変更やその他のさまざまな部分を実行するためにカスタマイズしています。これは非常にうまく機能し、リリース手順を大幅に簡素化しました。

今週末、私たちのライブ サイトの 1 つで、サイトがプリコンパイルされていれば防げたであろう問題に気付きました (長い話です)。

そのため、AspNetCompiler MSBuild タスク (PhysicalPath 属性を使用して中間の発行フォルダーに向ける) を配置スクリプトに挿入して遊んでいましたが、「VirtualPath」オプションに関する質問があります。

この展開前の段階では Web サイトが IIS にないにもかかわらず、'VirtualPath' 属性の値を指定する必要があります。ここで、 aspnet_compiler.exeの関連する -v スイッチが、コンパイル中にサイト全体で使用される '~' ルート化された仮想パスを解決する際にこの値を使用することを確認しました。

つまり、ここで渡すものはすべて、展開時にアプリケーションの仮想ルートで なければならないということです。そうしないと機能しません。

ただし、このオプションで「/fake/fake」のようなものを渡し、マスターページの1つを相対ではなくアプリルートのURLを介してcssを参照するように変更して、これを試してみましたが、展開しても機能しました「/fake/fake」ではなく「/site」の仮想パスに。

それで、これに関する決定的な答えは何ですか?この VirtualPath の値が IIS 内のサイトの最終的な展開場所と正確に一致することを心配する必要はありますか? 変更が必要になった場合に備えて、展開プロジェクトにターゲット Web サーバーの仮想階層の知識を持たせたくないので、そうしないことを願っています。

4

1 に答える 1

5

プリコンパイルされたコードを分析しましたが、VirtualPath の設定に関係なく、プリコンパイラはアプリケーションをルートとするパスを相対パスに自動的に解決するようです。また、コンパイル済みの同じサイトをターゲット サーバーの別の仮想パスにデプロイしようとしましたが、何も壊れません。

したがって、私は自信を持って次のように言うことができます。いいえ、この値が何であるかは問題ではありません。

私が見逃している可能性のあるものがあることは間違いありませんが、私が間違っていることが証明されるまで、私は正しいと思います!

于 2010-08-10T12:29:41.470 に答える