ASP.NET プリコンパイル ツール aspnet_compiler.exe を使用して、デプロイ後にサイトをコンパイルしようとしています。
ブックの定義によると、Web マシンでインプレース プリコンパイルを実行すると、最初のページの読み込みエクスペリエンスが向上するはずです。コンパイル ツールは各 ASP.NET ページをコンパイルし、コンパイルされたバージョンを%WINDIR%\Microsoft.NET\Framework\v4.0.30319\TemporaryASP.NET Files フォルダーに保存します。これは、各ページがブラウザーから初めてアクセスされた場合と同様です。インプレース プリコンパイルを使用すると、ランタイムでこの手順を実行する必要がなくなるため、サイトに新しく展開された ASP.NET ページに対して行われる最初の要求を高速化できます。
何らかの理由で、期待どおりに機能しません。
aspnet_compiler.exe を Web マシンで手動でローカルに実行する場合:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /7.1 -p C:\MyPathToWebSite\www
次の構造構造のフォルダーを作成しました。
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\7.1\640c1f87\4be3507b
ブラウザーを使用して Web ページにアクセスしようとすると、ASP.NET は同じサーバーの次のフォルダーに別のキャッシュ バージョンを作成します。
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\7.1\bc8a1bb3\42b014d4
ご覧のとおり、プリコンパイルは両方のシナリオ (手動と IIS) で機能しますが、どういうわけか、IIS は、ページが既にプリコンパイルおよびキャッシュされ、すべてを再コンパイルしようとしているのを認識しません。aspnet_compiler.exe にはインプレース コンパイル用のパラメーター オプションが制限されているため、何が不足しているのか、何が間違っているのかわかりませんでした。
これまでのところ、一時 ASP.NET キャッシュに関するテスト/調査中に次のことを試みました。
- ユーザー関連ではないようです。どのユーザーが手動で実行しているかは問題ではありません
- 同じフォルダーが異なるサブネットの異なるサーバーに作成されるため、ソース/ターゲット IP には関係ありません。
任意のアイデアと助けをいただければ幸いです。