私の開発マシンはWindows XP SP2（とIIS 5.1を含意しています）を実行しています。開発マシンIISバージョンと展開IISバージョン
最近まで、私たちの展開環境はWindows Server 2003（したがってIIS 6.0）をベースにしていました。
新しいプロジェクトのために、Windows Server 2008（したがってIIS 7.0）に移行しようとしています。
私たちのプロジェクトは、ASP.NET MVCとWCFサービスを使用しています。
開発マシンをアップグレードしてWindows Server 2008（またはVistaでも可能ですが、これはIIS 7.0に付属しています）をアップグレードする重要な理由はありますか？
開発マシンをアップグレードして、を実際の手段とリソースの中でできるだけ多くの実稼働環境のにエミュレートすることをお勧めします。そうしないと、開発マシンからサーバーの環境にアプリケーションを配備するだけで、IISのバージョン、各マシンが実行している.NETフレームワークのバージョン、まさにその方法に関係するアプリケーションを配備するだけで、トラップに陥る可能性がありますコードは実行時にコンパイルまたは実行されます。
IIS 5.1以降、IIS 7が大幅にアップグレードされて以来、いくつかの大きな機会を逃してしまう前に、開発中に現在の機能に近づけないといけませんか？実稼働環境のアプリケーションから何を期待するかを実際に知るには、同じ状況下でアプリケーションを開発します。
編集/追加：This link異なるバージョンがプロジェクトに与える影響の重要な例が少なくとも1つはあります。
あなたが展開する予定のものと同じ主要ビルドに対して開発することをお勧めします。つまり、いくつかの選択肢が残っています。まず、ローカルIISインストールに対して構築することができます（現状のように）。つまり、すべてのボックスがWindows VistaまたはWindows 2008 Server（またはIIS 7.5を実行している場合はWindows 7）にアップグレードされる可能性があります。第2の選択肢は、リモートマシンに展開することです。 IIS 7を実行しているリモートテストマシンにアプリケーションを展開し、リモートでデバッグすることも可能です。問題は、複数の開発者がリモートサイトで作業している場合、問題が発生することです。 IISは、さまざまな開発者向けに異なるWeb上でリモートデバッグを処理できますが、アーキテクチャや構成によっては、テストWebアプリケーションのインスタンス間でリソースを共有している可能性があります。唯一の利点は、すべてのマシンのライセンスを購入する必要がなく、OSのアップグレードをサポートするためにハードウェアをアップグレードする可能性があることです。しかし、私はそれが近視眼であると思う。開発者の生産性の低下は価値がありません、IMHO。
IIS 5.1とIIS 7.xの間に大きな変更があります。統合パイプラインなどのアーキテクチャの変更により、動作と互換性の問題が大幅に異なる可能性があります。私はあなたがIIS 7をはるかに開発者に優しいと感じるでしょう。要求トレースの失敗、拡張されたロギング、拡張されたエラーページなどの導入だけで、アプリケーションのエラーを追跡するのがずっと簡単になりました。その点で、アップグレードには十分な価値があります。