我的开发机器正在运行 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(或可能是 Vista,因为这也带有 IIS 7.0)有什么关键原因吗?
我的开发机器正在运行 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(或可能是 Vista,因为这也带有 IIS 7.0)有什么关键原因吗?
我会说升级您的开发机器以在您的能力和资源范围内尽可能多地模拟生产环境符合您的最大利益。否则,您可能会陷入您完全没有意识到的陷阱,只是将应用程序从开发机器部署到服务器环境,这可能与不同版本的 IIS、每台机器运行的 .NET 框架版本或方式有关代码在运行时编译或执行。
尤其是 IIS 7 自 IIS 5.1 以来已进行了大幅升级,为什么您不应该在开发过程中更密切地使用它的当前功能,以免错过一些大好机会呢?要真正了解生产中的应用程序会发生什么,请在相同的情况下进行开发。
编辑/添加:此链接可以帮助您了解至少一个重要示例,说明不同版本如何影响您的项目。
我建议您针对打算部署的相同主要版本进行开发。也就是说,这给您留下了一些选择。首先,您可以针对您的本地 IIS 安装进行构建(就像您目前所做的那样)。这意味着您的所有机器都应该升级到 Windows Vista 或 Windows 2008 Server(或运行 IIS 7.5 的 Windows 7)。您的第二个选择是部署到远程机器。完全可以将您的应用程序部署到运行 IIS 7 的远程测试机器并进行远程调试。问题是,如果您有多个开发人员在远程站点上工作,就会出现问题。IIS 可以为不同的开发人员处理不同 Web 上的远程调试,但取决于您的架构和配置,您可能仍在测试 Web 应用程序的实例之间共享资源。您有时可能会彼此死锁。唯一的好处是您不必为所有机器购买许可证(并且可能升级硬件以支持操作系统升级)。但是,我认为这是短视的。恕我直言,开发人员生产力的损失是不值得的。
IIS 5.1 和 IIS 7.x 之间存在重大变化。对架构的更改(例如集成管道)可能会导致截然不同的行为和兼容性问题。我想您会发现 IIS 7 对开发人员更加友好。仅引入失败请求跟踪、扩展日志记录和增强错误页面等功能就可以更轻松地跟踪应用程序中的错误。在这方面,升级是非常值得的。