Visual Studio 2010 Service Pack 1 General Availability

Visual Studio 2010 Service Pack 1 General Availability

  • Comments 29

If you guys follow Jason Zander’s (Visual Studio corporate Vice President) blog, you learned two days ago that the Visual Studio 2010 Service Pack 1 whose Beta had been released last December achieved final release stage. Today is generally available (last Tuesday was only for MSDN subscribers).

You can get it from here.

Let’s summarize the list of C++ new features and fixes that are included in this release. You’ll find an expanded description beyond C++ in this Microsoft Support article.

 

New C++ Features

MFC-based GPU-accelerated graphics and animations

Visual Studio 2010 SP1 enables the following two technologies for MFC:

You can take advantage of these two technologies without breaking the MFC programming model. Additionally, you can find demos in the following directory:

[drive]:\Program Files\Microsoft Visual Studio 10.0\Samples\1033\VC2010SP1Samples.zip

For more information about the technology improvements in Visual Studio 2010 SP1, visit the following website: MFC Additions for Visual Studio 2010 SP1.

New AMD and Intel instruction set support

Visual Studio 2010 SP1 adds intrinsic functions or intrinsics to enable the extensions on the AMD and Intel new microprocessors (being released this year). The intrinsic functions allow for highly efficient computing without the overhead of a function call. For more information about the intrinsic function, visit the following website: Compiler Intrinsics.

For more information about the extensions, visit the following third-party websites:

 

List of C++ Specific Issues that Are Fixed

Some link to the Connect bug, some don’t when the issue was found internally.

C++ Editor

C++ Compiler

Standard C++ Library

C Runtime (CRT)

Microsoft Foundation Classes (MFC) and Active Template Library (ATL)

C++ Debugging

For a complete list of new features and fixes, please visit this article.

 

ATTENTION: if you are to install Visual Studio 2010 SP1 in machines containing the stand-alone Microsoft Windows SDK for Windows 7 and .NET Framework 4, read this first.

  • Go To Definition is still too slow. One of my colleagues, who previously downgraded to 2008 specifically because of this problem, tried installing 2010 SP1 to see if it had improved. He opened the project, let Intellisense parsing finish, then hit F12 on a symbol. 5 minutes (!!!) later, he landed at the definition.

    This is the one thing holding us back from moving to 2010.

  • @Ben, I don't know if you have considered this already, but we use Visual Assist X to perform navigation and auto-completion. With the improved intellisense of VC2010 and further fixes of SP1 (non-creating ipch issue - thanks for fixing that!) it is a really a killer combo. "Go to definition" in ~1Mloc solution takes up to a second or two - in the worst case.

  • I just tried to install the VS 2010 SP1 after I previously installed the Windows 7 SP1 (x64).

    Message:

    Microsoft Visual Studio 2010 Service Pack 1 kann nicht installiert werden, da es vom aktuellen Zustand dieses Computers nicht unterstützt wird.

    English Translation: Cannot install SP1, as the actual state of the Computer is not supported. I guess that means it doesn't run on Windows 7 SP1 (x64)

    Additionally the message advices me to read the info file: It links me to www.microsoft.com/.../default.aspx. Not really helpfull.

    Any ideas?

  • @bEEf, yes, everyone at my workplace has a license of VisualAssist. I suppose VisualAssist's "Go To Implementation" (Alt+G) is a reasonable substitute. I'll try that for awhile. Thanks!

  • Answering to @Mathias and @Sam for now! (other answers I need official input from team members). Regarding @Mathias this is what I got:

    In VC2010, the user can no longer specify whether to bind to RTM or SP1. Whatever on the machine is what will get loaded. However, the user should make sure she/he ships the same CRT that was used during the test.

    Yet another answer to @Sam. The Windows SDK team suggests to check this page: go.microsoft.com/fwlink as they will post news in the next few days.

  • CORRECTIONS:

    VC10 SP1 does NOT contain a fix for connect.microsoft.com/.../558339 "tr1:regex has different behavior between vs2008 and vs2010 on some regular expression". This was fixed in VC11 only.

    VC10 SP1 CONTAINS a fix for connect.microsoft.com/.../vc10-algorithm-is-sorted-until "VC10 <algorithm> : Incorrect result from is_sorted_until". Of course, this was also fixed in VC11.

    The regex fix was considered for VC10 SP1, but rejected due to its complexity. While I personally feel really bad about this bug (it affects many complicated regexes), I couldn't guarantee that the inherently complicated fix wouldn't break anything else, so I agreed that it should be rejected.

  • I'm glad SPs aren't like IBM's old days of FIX packs (FPs).  I mean, why fix things in a service pack when you can just fix the NEXT version, hm?  After all, it's already fixed so why in the WORLD should the "old model" get what belong to the "new model", hm?

  • Yeah, it does seem absurd. Sometimes, it's like the whoever makes the decisions on Visual Studio thinks they're making fine wine, not an IDE. Apparently new code shouldn't be seen by the world until it's had time to "mature" for a couple of years in Microsoft's wine cellars.

    I'm sorry to break it to you, guys, but code doesn't work like that. And the whole "we'll only give you access to new features once every 2 years, when we ship a new version of VS" is just absurd. It only serves to make you less competitive. I can use any of the half-dozen competing compilers, and I'll get new features as they're ready. In terms of C++0x support, VS2010 was more or less on par with the competition for about two months after release. From that point, and until whenever VS2012 ships, you're back in last place. Not because you haven't implemented more of C++0x, but because WE CAN'T BE ALLOWED TO USE IT.

    With Visual Studio (in general, although it hurts the most with MSVC specifically), a new feature is, on average, delayed by a year past what is needed for testing (assuming 2 years between VS releases, and assuming the development of new features is evenly distributed across those 2 years).

    Bug fixes, I guess, are "only" delayed by half a year, as they have a chance of getting in through a service pack.

    But really, this is 2011, there's zero excuse for this any more. It may have made sense in the 80's, but today? If you have something new that makes your product better, SHIP IT! Get it into your users hands. That way, your users might still want to be your users next year.

    You (STL, I believe it was?) already said that you've got the `thread` header implemented and ready to go. And yet, we can't have it until VS2012. How exactly does this benefit *anyone*? How does it make VS more competitive? And how does it help us write better software?

    And of course, I realize that the VC team's hands are probably tied on the matter. I somehow doubt you'd be allowed to go shipping new features at will, while other VS languages are stuck with the old "only ship anything worthwhile as part of a major product release" cycle. But that doesn't make it any less ridiculous.

  • oh good grief. Who thought popping up a MODAL dialog while the IDE figures out the "go to definition" thing?

    I'm not really bothered about the time it takes, but that it locks up my IDE in the meantime is ridiculous.

    If you're going to spend more than 5 seconds determining where to jump to, come up with a more discreet solution. Perhaps you could let it run in the background, and when it's done, pop up a small (non-modal) dialog or panel with a button or link , which I can click if I still want to jump to the definition I asked for earlier.

    I'd have thought the #1 rule for any IDE would be "don't prevent the user from working". If that isn't the #1 rule, then it should be. Blocking the IDE is unacceptable. It was unacceptable when it was the help viewer doing, it, it's unacceptable when "go to definition" does it, and it's unacceptable at any other time as well.

  • There is no dll hell as long as they remain abi compatible.  I assumed that the vc++ team understood this when they announced no more sxs vc runtimes.  Hopefully they do.

  • Here's what I meant by DLL Hell.  Somebody goes and sets OVERWRITEALWAYS on the mfc100.dll in system32 (syswow64) and installs an older version (i.e. not the SP1 version).  Now your app is referring to new Direct2D classes and stops working because it has an older version of mfc100.dll in system32 (the original RTM version).  

  • @ Angry_dev (11 Mar 2011 1:45 AM)

    Thanks for reporting this issue. We would like to investigate this further with your help. If possible can you please send me an email at sumit dot kumar at microsoft dot com with a screenshot of what you are seeing.

  • Can we get a sp for VS 2008 since the last one is well over 2 years old?  

  • @Tom, what is exactly what you'd like VS2008 to get fixed? It may exist a Hotfix depending on your issue, or possible VS2010 comes with that issue already fixed.

Page 2 of 2 (29 items) 12