目前正在考虑为我们从 vs 2005 (winforms) 迁移到 vs 2008 (wpf) 提出论据。我的主要观点是新的 UI 设计功能。
我有点担心我们会投入大量工作来升级所有东西，只是为了在 2010 年到来时我们必须做同样的事情？因此，这导致还考虑跳过 2008 年，并在 2010 年发布后立即采用。
有人遇到过类似情况吗？
还有任何支持和反对欢迎的论点。
干杯。
【问题讨论】：
标签： visual-studio visual-studio-2008 visual-studio-2010
我个人认为进入 2008 年是相当安全的，因为 2010 年只是在它之上的扩展和对 WPF 的 Visual Studio 设计时支持的增强。因此，过渡不应该那么复杂。更像是 2005-2008 年 Win Forms 或 ASP.NET 项目的升级，这是小菜一碟。
我发现最好尽早升级，这样您就不会“陷入”现有框架/系统的困境。如果您继续在最终将要替换的东西上进行构建，则越来越难以证明管理层采取行动的合理性。
【讨论】：
我也遇到了同样的情况，并选择了 MSDN 订阅路线，在那里我获得了所有新的开发工具。我有一台备用机器，用于编译器的“下一个版本”，用于迁移测试，因此我至少知道必须做出决定时会发生什么。这对我来说效果很好，我想如果你有一个像样的虚拟化设置会更好。
新的编译器版本并没有破坏我的构建，但确实损害了我的许多自动化测试和插件生产力工具。基本上。您需要进行某种回归测试以确定迁移到新版本可能造成的损害。
【讨论】：
你的问题对我来说不是很有意义。您是否在问是否应该将现有应用程序从 Winforms 迁移到 WPF？或者您只是想开始制作新的 WPF 应用程序，但仍要使用现有的 Winform 项目？
无论哪种方式，从 Visual Studio 2005 迁移到 2008 都非常简单。现有的 Winform 项目需要几秒钟的转换，对我来说从未失败（过去几个月转换了数十个解决方案和 100 个项目）。
但是，这与 Winforms 和 WPF 无关。
如果您想开始构建 WPF 应用程序，没有理由等待 VS 2010。VS 2008 对这两种应用程序类型都有出色的支持。
【讨论】：
我同意那些建议现在采用 VS 2008 的人。不过要考虑的一件事是 WPF 具有相当高的学习曲线。我对 WPF 和 Silverlight 的接触有限，我发现它们是 WinForms 模型的完全“思想转变”。祝你好运。
【讨论】：
如果我站在你的立场上，我现在就会跳槽。通过让您习惯许多您已经必须习惯的新功能，它将最大限度地减少 2010 年跳线的影响。此外，在 2010 年推出之前，您将享受数月的更好性能和功能。
【讨论】：
Winforms 与 WPF 是天壤之别。与从 2005 年迁移到 2008 年相比，这是一个更大的变化。我不会将其作为升级到 2008 年的驱动理由。我也不知道您的项目范围以及 WPF 是否真的是您的最佳选择产品。或者，如果表达式混合是让这些 UI 运行所需的全部工具。
我将专注于您可以立即获得的真正好处，而不是宣传 WPF。在 2008 中，您具有多目标，因此您可以构建您在 2005 中构建的所有应用程序，并让它们以 2.0 框架为目标。根据我的经验，我发现 2008 更快，重构改进是一个很好的补充。 2008 年还有许多其他新改进，您可以立即使用，从第一天开始就可以使用。
根据 2010 年首席架构师 Rico 的说法，您将在 2010 中获得更丰富的多目标，这将允许您更早地采用 2010，而不是强迫您从一开始就使用 CLR 版本 4。
【讨论】：
目前我已经养成了尽快升级到最新版本的习惯。尽管对于应用程序开发人员来说，它有自己的陷阱，例如。 .Net Framework 3.5 在大多数计算机上都找不到，如果我提供 20 MB 的引导安装程序，它会坚持使用活动的 Internet 连接来下载所需的文件。完整的安装程序是 198 MB，虽然我不喜欢它，但我必须将它与软件一起提供。
对于 Web 开发人员来说，虽然问题更容易解决，但您只需要担心使其在服务器上工作，并且事情会自动为用户工作。因此，如果您正在制作 Web 解决方案，我认为迁移更容易。
如果您正在制作应用软件，我认为您应该权衡迁移所带来的优势以及它将对您的部署方案所做的更改。我不知道有多少人会同意这一点，但我认为应用程序开发人员应该落后一个升级。
【讨论】：
这里有一个我认为不应忽视的潜在流程问题：
什么时候是升级开发工具和生产环境的合适时机？
一方面，您可以跳过 2008 年，但这会导致何时采用 2010 年的问题：在首次发布、首次服务包发布或其他里程碑时？如果您在 2005 年使用 2.0 框架而其他人转向其他框架，这可能会导致创建更多遗留代码。即使您切换到 2008，它仍然可以针对 2.0 框架，因此 .Net 框架的升级可能会单独发生，有些人可能会喜欢。这个阵营的另一个关键点是谁做研究来评估版本之间的差异，看看哪个值得转变。
另一方面，您可以建议有一个持续的策略，即准备每 3 年左右升级一次，因为过去十年的 Visual Studio 版本到目前为止大约是 2002 年、2003 年、2005 年和 2008 年。在我看来，这似乎是更好的方法，因为有更多的持续进化在进行，而不是完全被锁定。在这种情况下，可能会使用新功能，因为与第一种情况相比，新工具来得很快2-3 年。
当然，正如我所说，我的旧工作机器有 Visual Studio 2003、2005 和 2008，所以我有点属于后者，这对我来说很有意义。我记得 10 年前我的工作机器有 NT 4.0、Pentium II 333 MHz 处理器、64 MB RAM 和一个 4 GB 硬盘驱动器，它必须是 2 个分区，因为它不会让一个分区那么大。现在我的工作机器只有 4 GB 的 RAM、一个 2.66 GHz 双核处理器和一个 160 GB 的硬盘驱动器。再过 10 年，我能拥有一台拥有数百 GB RAM 的机器吗？虽然这看起来很荒谬，但如果我与少数其他开发人员共享一台机器，那么在我们所有人之间分配大量内存可能是有意义的。
【讨论】：