私の開発マシンは、Windows XP SP2 (および暗黙のうちに IIS 5.1) を実行しています。
最近まで、展開環境は Windows Server 2003 (したがって IIS 6.0) に基づいていました。
新しいプロジェクトのために Windows Server 2008 (したがって IIS 7.0) に移行しようとしています。
私たちのプロジェクトでは、ASP.NET MVC と WCF サービスを使用しています。
開発マシンをアップグレードして Windows Server 2008 (または、IIS 7.0 も付属しているため、おそらく Vista) を実行する主な理由はありますか?
開発マシンをアップグレードして、手段とリソースの範囲内で可能な限り多くの実稼働環境をエミュレートすることが、あなたの最大の利益になると思います。そうしないと、開発マシンからサーバーの環境にアプリケーションをデプロイするだけでは、まったく気付かない罠に陥る可能性があります。これは、IISの異なるバージョン、各マシンが実行している.NET Frameworkのバージョン、またはその方法に関係する可能性があります。コードは実行時にコンパイルまたは実行されます。
特にIIS7はIIS5.1から大幅にアップグレードされているので、いくつかの素晴らしい機会を逃す前に、開発中に現在の機能に近づいてみませんか？本番環境のアプリケーションに何を期待するかを実際に知るには、同じ状況でアプリケーションを開発します。
編集/追加：このリンクは、異なるバージョンがプロジェクトにどのように影響するかについて、少なくとも1つの重要な例を確認するのに役立ちます。
デプロイする予定の同じメジャービルドに対して開発することをお勧めします。そうは言っても、これにはいくつかの選択肢があります。まず、ローカルのIISインストールに対してビルドできます（現在行っているように見えます）。つまり、すべてのボックスをWindowsVistaまたはWindows2008 Server（または、IIS7.5を実行しているWindows7）にアップグレードする必要があります。2番目のオプションは、リモートマシンに展開することです。アプリケーションをIIS7を実行しているリモートテストマシンに展開し、リモートでデバッグすることも完全に可能です。問題は、リモートサイトで複数の開発者が作業している場合、問題が発生することです。IISは、さまざまな開発者向けにさまざまなWebでリモートデバッグを処理できますが、アーキテクチャと構成によっては、テストWebアプリケーションのインスタンス間でリソースを共有している可能性があります。相互にデッドロックが発生する場合があります。唯一の利点は、すべてのマシンのライセンスを購入する必要がないことです（OSのアップグレードをサポートするためにハードウェアをアップグレードする可能性があります）。しかし、それは近視眼的だと思います。開発者の生産性を失うことは、それだけの価値はありません、私見。
IIS5.1とIIS7.xの間には大きな変更があります。統合パイプラインなどのアーキテクチャへの変更により、動作と互換性の問題が大幅に異なる可能性があります。IIS7の方が開発者にとってはるかに使いやすいことがわかると思います。失敗したリクエストのトレース、拡張ログ、拡張エラーページなどの導入だけで、アプリケーションのエラーの追跡がはるかに簡単になります。その点で、アップグレードはそれだけの価値があります。