Visual Studio 2010 Release Candidate Is Now Available For Download

Visual Studio 2010 Release Candidate Is Now Available For Download

  • Comments 59

We are very excited to announce the release of Visual Studio 2010’s Release Candidate. The official announcement can be found on Soma’s blog. You can download the RC from this location and it includes a go-live license for people who want to deploy in their production environment. This release incorporates many Customer Connect bug fixes and includes significant performance improvements.  Just like Beta2 you can log Customer Connect bugs for this release. Here you can find a list along with descriptions of what is new in Visual Studio 2010. We are excited to see your feedback and answer your questions.

 

Thank you,

 

Kelly Evans

Visual C++ Team

  • I love coding C++ D3D11 applications in VS2010.  Lambdas and the templates in the algorithms header go great together.

  • When would VC++ 2010 express edition RC would be released?

  • Congratulations! When will Express Edition be released?

  • Hi, I read the release launch date is set to April 12th 2010, but how about general availability/RTM date?

    Thanks!

  • Sorry for capturing this reply, but my question is burning holes into things ;)

    Is there any reason why ATL and CString use different CString implementations?

    With the CString revamp after VC6 I was very much hoping that they would be "united". Currently, this means for us that we have separate ATL and MFC builds for many libraries.

    It would be interestign to know the reasons for this separation.

  • @ Jagannath and Limal: We will not be releasing the Express SKU’s for the RC. It will be available at launch.

    @ Marc: Product will be available at launch.

    Thank you,

    Kelly Evans

    Visual C++ Team

  • Has the VC++ directories dialog been moved back into global options yet? It is the most glaring omission in the betas.

    If not, will it ever be?

  • The moving of the global project directories from an easily accessible place is a HUGE problem for any shared team environment. It is impossible to ensure that all developers have the exact same SDKs installed in the exact same paths and since these are now part of the project files it now means that project files cannot be shared across developers. For us this is basically a show-stopper for all use of 2010 which is a huge shame.

  • Ashira and Andrew, the old functionality is still in place, there just isn't an obvious UI for it. See http://blogs.msdn.com/vcblog/archive/2009/10/22/visual-studio-2010-beta-2-is-now-available-for-download.aspx#9913959

  • Not sure where to post this, so here goes.

    I just built my project with the RC, and there are some differences in std::string::operator[]. In previous versions, operator[](size_type _Off) performed this check for validation:

    if (this->_Mysize < _Off)

       _DEBUG_ERROR....

    Now it performs this check:

    if (this->_Mysize <= _Off)

       _DEBUG_ERROR....

    This means you can't index off the end of the string where the null-character is (e.g. mystring[mystring.size()]). This is admittedly a bad thing to do, but we have some code that relies on it, as it was originally coded for C-strings.

    Interestingly, the const version of std::string::operator[] still has the old check, and I can "fix" my broken code by using const strings, instead of non-const.

    I'm curious why this decision was made (both to change the non-const behavior and to introduce the discrepancy in behavior between const and non-const versions).

  • @peterchen: MFC uses the ATL CString class (see afxstr.h) and has done so since Visual Studio.NET, as far as I can tell.

    Pat Brenner

    Visual C++ Libraries Development

  • [Ben]

    > I'm curious why this decision was made (both to change the non-const behavior and to introduce the discrepancy in behavior between const and non-const versions).

    Our debug checks are intended to enforce the Standard's requirements to the greatest extent possible. During VC10's development, we discovered that string::op[]() contained insufficiently strict debug checks, so we tightened them up.

    The Standard prohibits access to the null terminator for modifiable strings and references, but allows access for const strings and references. The Standardese is C++03 21.3.4 [lib.string.access]/1:

    "const_reference operator[](size_type pos) const;

    reference operator[](size_type pos);

    Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(), the const version returns charT(). Otherwise, the behavior is undefined."

    Stephan T. Lavavej, Visual C++ Libraries Developer

  • >>Ashira and Andrew, the old functionality is still in place, there just isn't an obvious UI for it.

    Yes, we know it still exists, but it's a PITA to access it. I really want to see this back where it was before.

    For some, per-project configurations are better--but you've added those, haven't you?--and for some, the old global settings is better. Like for me, for instance.

    Killing this UI is the biggest VS-killer of this version. I am sadly thinking of staying away from it because of this.

    I know I complained about this before...

  • The UI is still there for setting directories globally; going into the property manager is just as easy as going into VS options, it just isn't as intuitive. I certainly wouldn't consider a different UI for the same functionality a "VS-killer".

  • @Ashira and Andrew Cross: It's not so hard to access the global settings: Open the Property Manager (View menu -> Other Windows -> Property Manager), then simply doubleclick on the Microsoft.Cpp.Win32.user property sheet. In there, set the global paths to whatever you like.

    A more convenient shortcut to opening this property sheet would be handy (for example so it can be opened without having a C++ solution open), but it's hardly "A PITA to access". It takes a few clicks more than before, but since it's effectively a global setting you might modify *once*, I think it's tolerable.

Page 1 of 4 (59 items) 1234