迁移到VS10是什么体验？
我们正在考虑将一个非常大的产品升级到 VS10。
我听说过很多关于 VS10 的好消息，并且对新的 C++0x 功能感到非常兴奋，但是在使用 VS10 时，我遇到过一个示例玩具应用程序崩溃的情况（在 VS8 中没有），并且一种情况似乎是 某些 C++0x 功能中的编译器错误。
在另一种情况下，我看到 unorderd_map 抛出 bad_alloc 异常，其中 VS9 中不会这样做。
我们的产品由本机 C++ 和 .NET 组成，有数百万行代码。有人有将类似项目迁移到 VS10 的经验吗？过程痛苦吗？此举是否造成了任何倒退？
我正在寻找更多轶事证据，因为我在网上找到的所有评论都很好，但与我的经历不符。
We're thinking of upgrading a very large product to VS10.
I've heard a lot of good things about VS10 and am very excited about the new C++0x features however when playing around with VS10 I had one case in which a sample toy application crashed (which it didn't in VS8) and one case in which there seems to be a compiler bug in some C++0x features.
In another case I see that unorderd_map throws a bad_alloc exception where it doesn't do so in VS9.
Our product is made up of native C++ and .NET and is several million lines of code. Does anyone have any experience with migrating a comparable project to VS10? Was the process painful? and were there any regressions created by the move?
I'm looking for more anecdotal evidence since all the reviews I found online were good and don't match my experience.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们也有一个类似的大型项目。我还没有运行代码行计数器，但我猜很容易有一百万行。大约有 200 个项目 - 大约 140 个 C++ 项目，全部使用 COM/DCOM 和 60 多个 .NET 项目，使用 Winforms/WPF/等的各种组合。我们有很多 COM 互操作和 PInvoke
我们之前使用的是针对 C++/C# 的 VS2008，目标是 .NET Framework 3.5SP1，现在已经迁移到针对 C++ 的 VS2010，目标是 .NET 4。
总体印象：
升级是“总体来说太痛苦了。大约花了一天的时间才将其启动并运行，然后另一对夫妇（分散在各个开发人员中）解决了其他剩余问题
我个人认为 VS2010 比 2008 更好，但这并不是主要的升级。好处来自语言改进（C++ 0x 和 .NET/C# 4）
项目不向后兼容。您的整个团队都必须立即跳跃。
它确实修复了一些烦人的问题，例如添加引用对话框，以及用于显示项目上的上下文菜单的愚蠢的长时间
IDE 崩溃的次数比 2008 年要少得多，但它仍然会崩溃。天。
新的 VS2010 附加组件非常简洁
“多显示器”支持并不是太多“支持”。您可以在 IDE 外部浮动许多单个代码窗口，但不能将它们停靠在一起。基本上，您会在主屏幕上看到选项卡，并在辅助屏幕上看到许多浮动窗口，这是相当无用的。
ClickOnce 仍然很糟糕！
您不必升级您的构建机器。只需在其上安装 VS2010 并调整 TFSBuildService 配置，使其了解 .NET 4
C++
不要安装“Power Commands”插件。当处理 C++ 项目时，它会搞砸 IDE。 （基本上，它使 IDE 每秒失去和获得焦点约 100 倍，这意味着您无法正确选择文本或使用键盘快捷键）
C++ 项目格式已从 .vcproj 更改为 .vcxproj。 Visual Studio 项目升级向导负责处理大部分事情，但它确实丢失了一些构建前/构建后步骤，我们必须手动将其放回原位。
您可以使用 VS2010，但仍以 VS2008 C++ 编译器为目标。我们最初是在迁移项目后这样做的，因为我们很谨慎。切换到 VS2010 编译器并不是什么大问题，所以我们在一两天后就开始使用它 - 我们让它从 STL 向我们抛出一些断言，但这些东西在技术上无论如何都是不正确的，所以我们只是修复了它们。 /p>
升级 C++ 项目时遇到的主要问题是项目依赖项现在存储在 .vcxproj 文件中，而不是存储在解决方案中。您知道如何右键单击项目，选择“依赖项”并勾选依赖项的框吗？这仍然会影响 VS2010 中的构建，但 MSBuild 不会关注它。这意味着您的构建机器构建几乎肯定会失败，因为构建顺序是错误的。您必须打开项目的属性页面，选择“框架和引用”并将依赖项放入其中。
这也意味着，如果您需要在 .NET DLL 之前构建纯本机 DLL（比如因为您 PInvoke 它），则不能依赖构建顺序工作！我们必须手动编辑 .NET 项目的 .csproj 文件，并将“引用”粘贴到本机项目中。这会导致 VS 抛出编译器警告，但这是使其按正确顺序构建内容的唯一方法< /p>
auto在 C++0x 中是蜜蜂的膝盖。VS2010 C++ 编译器编译我们的代码所需的时间与 2008 年编译器几乎完全相同。
.NET：
升级 C# 项目并不是什么大事。我们遇到的大多数问题都是由于冲突造成的，我们自己手动向后移植了一些类（例如 Tuple），并且必须删除向后移植。
.NET 4 非常乐意加载旧的 .NET 3.5 代码。我们的一位开发人员为整个 codeplex WPFToolkit 制作了一个自定义分支（别问，叹气）。 Microsoft 在 4.0 中将此工具包合并到 .NET core 中。我以为我们会因此产生大量冲突，但我们只是加载了分叉的工具包 dll，一切都顺利进行。
令人讨厌的例外是单元测试。您可以在 2010 年构建面向 .NET 框架 v2、3 或 3.5 的 .NET 应用程序，但 Visual Studio 只能加载面向 .NET 4 的单元测试项目。如果您使用的是内置的 Visual Studio 单元测试，这意味着您无需进行多目标。
修复 WPF 中的非模糊文本非常棒。我永远不会知道为什么他们多年来一直在提供一个损坏的文本渲染器。
他们加强了一些 COM 互操作性的东西。我们遇到了一些问题，.NET 抛出错误，因为我们的 pinvoke 签名上的调用约定是错误的 - 3.5 会默默地为您解决这个问题。不过这些很容易修复
如果您还有其他问题，请随时询问:-)
We also have a similar large project. I haven't run a line-of-code counter, but I'd guess there's easily a million. There's approx 200 projects - about 140 c++ projects, all using COM/DCOM and 60-odd .NET ones using various combinations of Winforms/WPF/etc. We have a lot of COM interop and PInvoke
We were previously on VS2008 for C++/C# and targeting the .NET framework 3.5SP1, and have moved to VS2010 for C++ and targeting .NET 4.
Overall Impressions:
The upgrade wasn't too painful overall. It took about a day to get it up and running then another couple (spread out amongst various devs) to iron out other remaining issues
Personally I find VS2010 better than 2008, but it's not that major of an upgrade. The benefits come from the language improvements (C++ 0x and .NET/C# 4)
Projects are not backwards compatible. Your entire team all has to make the jump at once.
It does fix a few annoying things though like the add reference dialog, and the stupidly long amount of time it used to take context menus on projects to appear
The IDE crashes a lot less than 2008 did, but it still crashes every couple of days.
The new VS2010 add-ons are quite neat
The "multi-monitor" support is not much "support". You can float lots of single code windows outside the IDE, but you can't dock them together. Basically you get tabs on your primary screen, and lots of floating windows on your secondary screen which is fairly useless.
ClickOnce still sucks!
You don't have to upgrade your build machine. Just install VS2010 on it and tweak the TFSBuildService config so it knows about .NET 4
C++
DO NOT install the "Power Commands" addon. It screws up the IDE when working with C++ projects. (basically it makes the IDE lose and gain focus about 100x a second which means you can't select text or use keyboard shortcuts properly)
The C++ project format has changed from .vcproj to .vcxproj. The visual studio project upgrade wizard takes care of most things, but it did lose a few pre/post build steps which we had to manually put back in place.
You can use VS2010 and still target the VS2008 C++ compiler. We initially did this after migrating the projects, as we were being cautious. It wasn't a huge deal switching over to the VS2010 compiler so we went for it after a day or two - we had it throw some asserts at us from the STL, but these things were technically incorrect anyway so we just fixed them.
The main issue we had with upgrading the C++ projects is that project dependencies are now stored in the .vcxproj files, and NOT in the solution. You know how you right-click on a project, select "Dependencies" and tick the boxes for the dependencies? This still affects building in VS2010, but MSBuild pays no attention to it. This means your build-machine builds will almost certainly break because the build order will be wrong. You have to bring up the properties page for a project, select "Framework and References" and put the dependencies in there instead.
This also means that if you need to build a pure native DLL before a .NET dll (say because you PInvoke it) you can't rely on the build order working! We had to manually edit the .csproj file of the .NET project and stick a "reference" to the native project in. This causes VS to throw a compiler warning, but it's the only way to make it build things in the right order
autoin C++0x is the bees knees.The VS2010 C++ compiler takes almost exactly the same amount of time to compile our code as the 2008 one did.
.NET:
Upgrading C# projects is a non-event. Most of the issues we had were due to conflicts where we'd manually backported some classes (like Tuple) ourselves and had to delete the backports.
.NET 4 is astonishingly happy to load old .NET 3.5 code. One of our developers had made a custom fork of the entire codeplex WPFToolkit (don't ask, sigh). Microsoft folded this toolkit into the .NET core in 4.0. I thought we'd have a ton of conflicts from this, but we just loaded the forked toolkit dll and everything worked seamlessly.
The annoying exception to this is unit tests. You can build .NET apps in 2010 that will target v2,3, or 3.5 of the .NET framework, but visual studio can only load unit test projects that target .NET 4. If you're using the built in visual studio unit testing, this means no multi-targeting for you.
Fixing the non-blurry text in WPF is great. Why the heck they shipped for years with a broken text renderer I'll never know.
They've tightened up some of the COM interop stuff. We had a few issues where .NET threw an error because the calling convention on our pinvoke signatures was wrong - 3.5 would silently fix this up for you. These are easy to fix though
If you have any more questions, feel free to ask :-)
@猎户座爱德华兹
这绝对是不正确的，并且在一般情况下不会发生（否则每个人都会在我们家门口）。请打开一个连接错误，以便我们可以调查并修复它。
谢谢——丹/msbuild。
@Orion Edwards
This is definitely not correct, and does not happen in the general case (or everyone would be at our door). Please open a Connect bug, so we can look into this and fix it.
Thanks -- Dan/msbuild.
除了 c++0x 功能之外，VS2010 中 c++ 的最佳功能是您可以更轻松地禁用智能感知。它现在是一个内置选项。
您甚至可以告诉智能感知仅解析和索引出现在解决方案中的文件。这样，如果您包含一个 boost 标头，或者只是一个非常庞大的代码库，它就不会像 VS2008 和 2005 那样尝试对其进行索引并崩溃。
The best feature in VS2010 for c++ besides the c++0x features is that you can disable intellisense more easily. It's now a built-in option.
You can even tell intellisense to only parse and index files that appear in your solution. That way if you include a boost header, or just a really huge code base, it doesn't try to index it and crash like in VS2008 and 2005.
虽然我仅将一个小型本机 C++ 应用程序（约 100,000 行）迁移到 Visual Studio 2010，但我尚未遇到任何编译器错误。
根据我的经验（无论是此应用程序还是其他更大的应用程序），升级到最新版本的 Visual Studio 是值得花费时间和精力的。 Visual C++ 随着每个版本的发布而变得越来越好，因此新编译器错误的风险通常可以通过编译器、标准合规性和开发环境的改进来抵消。
While I've only migrated a small native C++ application (~100,000 lines) to Visual Studio 2010 I've yet to encounter any compiler bugs.
It's been my experience (both with this application and other, larger, applications) that upgrading to the latest version of Visual Studio is worth the time and effort. Visual C++ gets better with each release so the risk of new compiler bugs is generally offset by improvements to the compiler, standards compliance, and the development environment.
作为迁移的一部分，有两件事让我很恼火：
如果您使用 VS2010 工具，托管 c++ 项目将被迫引用 .Net 4 框架（您可以在幕后摆弄并保留 VS2008 工具，以便您可以针对 .Net 3.5）等）
有些事情很有趣我的托管 c++ DLL 中的输出路径导致它们在项目文件中具有 path\\path 而不是 path\path 。这导致 VS2010 无法使用 DLL 作为对其他项目的引用。
这两个对我来说都不是阻碍，但当我升级我的项目时却出乎意料。
Two things that have annoyed me as part of the move:
Managed c++ projects are forced to reference .Net 4 framework if you use VS2010 tools (you can fiddle behind the scenes and keep the VS2008 tools so you can target .Net 3.5 etc)
Something was funny with the output paths in my managed c++ DLLs that caused them to have a path\\path rather than path\path in the project files. This resulted in VS2010 not being able to use the DLLs as references to other projects.
Both of these were not show stoppers for me, but were unexpected when I upgraded my projects.