最近、ASP.NET WebサイトからWebアプリケーションに移行しました。より具体的には、最近ASP.NETフォームのWebサイトを開発する代わりにMVCを採用しています。
非常にイライラするのは、コンパイルされたコードの小さな変更をテストするときの、ビルド->変更->再ビルドのプロセスです。 Visual Studioがコンパイルプロセスを完了するのを20〜25秒待つのを避けるために、ビルド間でいくつかの変更を「バンドル」していることに気づきました。 VSテンプレートからクリーンなMVC 4プロジェクトを作成し、1行のコード変更を行った後、ビルドの時間を測定しました。19秒かかりました。
ASP.NET Webサイトのコードビハインドに変更を加えると、次にページにアクセスしたときに、ページがオンザフライで再コンパイルされているように見えます。これは、小さなコード変更のたびにVS全体を強制的に再構築するよりも、Web開発のより良い環境のように思えます。
過去には、変更を加えたり、ブラウザーで更新を押したり、結果が表示されるまで1〜2秒待つという贅沢を楽しんでいました。これは、Visual Studioを使用して構築されたWebアプリケーションで実現できますか?
「編集して続行」オプションの有用性を見落としていたようです(Tools -> Options -> Debugging -> Edit and Continue)
地獄のダイアログメッセージを乗り越えるのに苦労した後:
次の場合は変更できません。
- すでに実行中のプロセスにデバッガーがアタッチされている場合。
- デバッグされるコードは、ビルド時または実行時に最適化されました。
- デバッグされているアセンブリは、ドメイン中立として読み込まれます。
- デバッグ中のアセンブリはリフレクションによって読み込まれました。
オプションがVSオプションでチェックされているにもかかわらず、個別のWebアプリケーションごとに有効にする必要があります。プロパティページでは、右下にある[編集して続行]までスクロールすると、Webタブに表示されます。
エディットコンティニューを使用して小さな変更を加えることは、Webサイトプロジェクトにコードビハインドを変更することとはまったく同じではありませんが、コードを変更するたびにアプリを再起動するよりもはるかに魅力的です。
サイトの実行中にMVCビューを編集できます。コントローラーのコードとその間のすべては、変更後に再コンパイルする必要があります。 ASP.NETを使用する場合、すべてを.aspxで記述しましたか?
とにかく、コードの1行を変更した後のインクリメンタルビルドでは、20秒は非常に長くなります(変更したwhatに依存する場合がありますが、いくつかのアセンブリをカスケードする場合があります)。最初にコンパイル速度について説明します。なぜ時間がかかるのですか? NuGetパッケージの復元?大量のアセンブリをコピーしていますか?ディスクドライブ、CPU、メモリが遅い?
一方で、開発プラクティスは少し最適ではないようです。テスト駆動開発を採用したい場合があります。ここでは、意図を示すためのテストを記述してから、実装に取り掛かります。これにより、開発用ウェブサーバーとブラウザが起動するのを待つ必要がなくなります。 Visual Studioからテストを実行します。