从 Visual Studio 2005 升级到 Visual Studio 2008 的陷阱
我读过很多文章，宣扬从 VS 2005 迁移到 2008 的优点。但是，我很想听听实际迁移过程中存在哪些陷阱。 我们即将迁移，我更愿意知道要预测和计划哪些减速带，而不是一路上意外地发现它们。 任何对此有帮助的指导将不胜感激，以便该过程尽可能轻松。
哦，我们主要是一家 C++ 开发公司，拥有一些中等规模的产品和一堆小型辅助工具。 我们对所有事情都使用外部 makefile，以便所有构建都很容易自动化。 有关迁移此类开发操作时会发生什么的具体见解将是最有帮助的。
先谢谢您的帮助！
I've read a number of posts touting the merits of migrating from VS 2005 to 2008. However, I'd love to hear what the various pitfalls are in actually doing the migration. We're about to migrate and I'd prefer knowing what speed bumps to anticipate and plan for instead of discovering them by surprise along the way. Any helpful guidance on this would be much appreciated so that the process is as painless as possible.
Oh, we're primarily a C++ development house, with a handful of moderate size products and a bunch of small ancilliary tools. We use external makefiles for everything so that all builds are readily automated. Specific insights about what to expect when migrating this type of development operation would be most helpful.
Thanks in advance for the help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果您使用任何 Visual Studio 插件，您可能会遇到兼容性问题 - 当我们第一次切换到它时，还没有支持 2008 的 Resharper 版本，所以这在当时是一个小问题。 除此之外，IDE 本身并没有真正遇到任何问题。 话虽如此，我们并没有做很多 C++ 工作，所以我不确定您的情况可能有多大不同。
想想看，我们在切换时遇到的唯一其他问题涉及使用 nant 构建 .Net 3.5 应用程序。 您没有说您使用什么构建工具，或者您是否执行任何托管代码，所以我不确定这对您来说是否会成为问题。 如果是的话，网上有一些解决方法可以让 nant 与 3.5 应用程序一起工作，其中涉及调整 nant 的配置文件。 如果您希望我发布它，请告诉我。
On the off chance you use any Visual Studio plugins, you may experience compatibility problems - when we first switched to it, there wasn't a version of Resharper out yet that supported 2008, so that was a minor issue at the time. Beyond that, we haven't really had any problems with the IDE itself. That being said, we don't do a lot of C++ so I'm not sure how different your situation may be.
Come to think of it, the only other problem we had with the switch involved building .Net 3.5 apps with nant. You didn't say what build tools you use or if you do any managed code so I'm not sure if this would be a problem for you. If it is, there are some workarounds on the net for getting nant to work with 3.5 apps which involve tweaking nant's config files. Let me know if you'd like me to post it.
我之前公司的升级经历如下：
My previous company's upgrade experience was as follows:
我们发现它并不完全可靠； 大多数时候都很好，但我们中的一些人有过几天似乎每五分钟就会崩溃一次。 坦率地说，它也感觉有点麻烦，例如。 SP1 尚未为我们修复一些资源的流动错误。
一些“链接时间代码生成”的东西显然在迁移过程中自动打开，在我看来，它太慢了。 链接时间从 30 秒缩短到 7 分钟，让人难以接受。 再次关闭它......
从好的方面来说，调试速度要快得多，当您在一些耗时的代码中遇到错误时，这是一个很大的优势。 不过，我们对发布构建速度并不确信。
尽管如此，其他语言中可能有很多精彩的功能，但据我所知，Visual C++ 团队在这三年里显然并没有那么忙（或者可能只剩下其中的两年了？）。
We've found it to not be totally reliable; most of the time it's fine, but a couple of us have had days where it just seems to crash every five minutes. Frankly it feels a little buggy too, eg. there's some itinerant bug with resources that SP1 hasn't fixed for us.
Some "link time code generation" thing got turned on apparently automatically during the migration, and IMO it's too slow. Link times going from 30 seconds to 7 minutes were pretty hard to swallow. Turned that back off again...
On the plus side, debugging is considerably faster, which is a big plus when you have a bug in some time-consuming code. We're not convinced about release build speeds though.
Still, there might be lots of wonderful features in other languages, but as far as I can see the Visual C++ team apparently haven't been that busy in the intervening three years (or maybe there are only like two of them left?).
我在使用 Visual Studio 2008 时遇到的唯一问题是它非常慢，直到我对其进行了一些调整。 我在退出调试模式时遇到了大约 8-10 秒的延迟 - 非常烦人。 SP1 以及修改一些 IE 设置也起到了帮助作用。
但除此之外，我对此很满意。
The only issue I have had with Visual Studio 2008 is that it was quite slow until I tweaked it a bit. I was running into a delay coming out of Debug mode on the order of 8-10 seconds or so - was quite annoying. SP1 helped out as did modifying some IE settings.
But otherwise, I've been happy with it.
我们上个月刚刚完成升级。 我没有注意到速度变慢 - 但我们从一开始就运行 SP1。 我们错误地安装了 SP1 的测试版（服务包测试版？！？！），并且必须在安装 RTM SP1 之前下载并运行一个特殊工具来删除它，但这不会影响您。 最大的痛苦是为我们的一个客户构建 2008 年的所有第三方库，并使用批处理流程将我们的项目和解决方案反向转换为 2005 年的版本。 关于库 - 微软表示，如果它的公共接口中有任何 C++，或者在内部使用 STL，那么它需要使用新的编译器进行重建。 我在我的博客。
编辑：这是我们使用的项目转换器。 我将其转换为用于批处理的命令行应用程序，并且效果很好。
We just finished upgrading this past month. I haven't noticed a slowdown - but we have been running SP1 from the start. We made the mistake of installing a Beta version of SP1 (beta for a service pack?!?!) and had to download and run a special tool to remove it before installing the RTM SP1, but that should not affect you. The biggest pain has been building all our third-party libs for 2008 and getting a batch process working to back-convert our projects and solutions to 2005 for one of our customers. About the libs - Microsoft says if it has any C++ in the public interface, OR uses STL internally then it needs to be rebuilt with the new compiler. I wrote up a little synopsis on my blog.
Edit: Here is the project converter that we used. I converted it to a command line app for our batch process, and it works pretty well.
可靠性大大提高。 日常功能设置不变（这是应该的）。
Reliability much improved. Everyday feature set unchanged (which is as it should be).
我在没有意识到这一变化的情况下遇到了一个问题（我也有一个问题帖子）安装程序的行为可能会有所不同。 旧的升级更多的是卸载和重新安装。 新的进行了就地升级。 这可能会导致问题：
需要将版本信息放入 DLL 中 - 不错，但可能不是自动化的步骤
One gotcha I've encountered without being aware of the change (I have a question post on it too) Installers can behave differently. The old upgrade was more an uninstall and a reinstall. The new one does an in-place upgrade. This can lead to issues:
need to put version info into DLLs - no bad thing, but may not be a step ytou've automated
out of the box, a service can not auto-upgrade, you need to force the user to uninstall the old and then install the new (TODO: citation for my question post to be added here)
我只遇到了两个问题。
当我们第一次使用 RTM 迁移到 2008 年时，一些第 3 方加载项无法工作。 我不记得是哪些，但我还没有在我们当前使用的任何加载项中遇到过这种情况。
如果您使用的是 Team Edition 或 Team Suite，则某些 3rd 方签入策略不起作用，因为它们引用了 2005 TFS API。 我们可以通过使用我们的代码的适当引用重新编译（例如从 CodePlex 中提取的内容）或重写策略来解决这个问题，因为它们相当简单。
正如我提到的，我们遇到的唯一问题是第三方可扩展性，几个月后没有出现任何问题。
I have only ran into two problems.
A couple of 3rd party add-ins did not work when we first moved to 2008 with the RTM. I do not remember which ones, but I have not run into this with any of the add-ins that we are currently using.
If you are using a Team Edition, or Team Suite, there are some 3rd party check-in policies that do not work because they referenced the 2005 TFS API. We were able to get around that by either recompiling with the appropriate references for things we had code for (like things pulled down from CodePlex) or rewrote the policies, since they are fairly simple.
Like I mentioned, the only issues we had were with 3rd party extensibility, and no issues in months.