DotNetNuke をフレームワークとして使用し、必要な機能のカスタム モジュールを使用して Web アプリケーションを開発しています。問題は、コードに変更を加えると Web サイトの読み込みに時間がかかることです。再起動ごとに最大 1 分を見ていますが、これは非常に遅いです。これにより、開発、再構築、テストのサイクルが非常に遅くなります。
コンソール プロジェクトと winforms プロジェクトの両方を、開発を高速化するための新機能のテスト グラウンドとして使用していますが、ブラウザで実行する必要がある UI 機能はまだたくさんあります。
Web アプリの bin フォルダーで何かが変更されたときに発生するアプリドメインの再起動を高速化/防止する方法に関するヒントはありますか?
DNNは、ページを追加/変更するときにオンデマンドでコンパイルを行います。ページを事前にコンパイルすると、ターンアラウンドタイムがはるかに速くなります。
大規模な Web アプリで使用すると、ASP.NET の欠点にぶつかります。
DotNetNuke には多数の重要な DLL と VB ファイルが含まれており、1 つの DLL を変更するだけですべてを再処理する必要があります。ビンに 50 個のモジュール DLL がある場合、50 個のモジュール DLL はすべて、次のアプリケーション要求時に ASP.Net によって再処理されます。
これが私の提案です：
次のフォルダーをソース管理に接続します (DNN フォルダー全体ではありません)。
開発者の 1 人が反復的なコンパイルやページの読み込みを必要とする場合、bin フォルダー内の DLL をできるだけ多く排除することで、開発者は最大の利益を得ることができます。可能であれば、テスト用にベアボーン スキンを使用することも役立ちます (非常に簡単に作成できます)。
ベアボーン スキン (多くても 1 つまたは 2 つのスキン オブジェクトを使用する必要があります) と、最小限の DLL (DNN コア + 独自の最低限のもの) を使用すると、開発に最適な速度が得られます。
開発者が 1 つのモジュールの集中的な開発を完了すると、ソース管理 (ここでは svn) からアイテムを削除したフォルダーを更新し、完全な DLL/スキン セットのコンテキストでコードのテストを終了できます。悩ませる。
時にはそれは苦労する価値があります。ASP.NET の再処理を数秒に短縮することはできませんが、10 ～ 15 秒に短縮することはできます。（SSDで実行していると仮定します）
生産が再開される限り、APPプールが営業時間外にリサイクルされることを確認してください.
マルチコアのセットアップがこの再処理時間を何らかの形で短縮できるかどうかを調べましたが、運がありませんでした (serverfault に関する未解決の質問があります)。
多分これはあなたを助けるでしょうか？