Microsoft delivers near-final Visual Studio 2013 Release Candidate

Microsoft delivers near-final Visual Studio 2013 Release Candidate

Summary: Microsoft is making available to developers the near-final test build of its Visual Studio 2013 development suite.


Microsoft is making available on September 9 to any and all interested testers the near-final Release Candidate of its Visual Studio 2013 development suite.


The Release Candidate (RC) can be downloaded starting around 10 a.m. PST/1 p.m. EST on September 9. The download is available under a "Go Live" license.

The Visual Studio 2013 RC leaked to the Web a week ago. Microsoft also made the RC available to its own employees and a limited number of developers outside the company, according to my sources.

Today, Microsoft is making the Visual Studio 2013 RC available broadly, and is commiting to have the RTW (release to Web) version available on October 18. October 18 is also the day Microsoft is making Windows 8.1 generally available, and the day it is opening the Windows Store for Windows 8.1-optimized applications from third-party devs.

Microsoft also announced today that it is going to make the release-to-manufacturing (RTM) bits of Windows 8.1 and Windows Server 2012 R2 available to those with MSDN/TechNet subscriptions on September 9. Microsoft officials had decided against releasing the RTM bits early, but reversed course after receiving developer feedback against that move.

Visual Studio 2013 -- and Net 4.5.1 -- add support for asynchronous debugging (when using VS 2013 on Windows 8.1, not older Windows releases) for C#, VB, JavaScript and C++ developers, among other features. The latest VS release also adds improvements for those using XAML, HTML and JavaScript to build Windows Store/Metro-Style apps. Microsoft made an initial public preview of Visual Studio 2013 available in late June of this year. 

Update: Microsoft is going to hold a post-RTW launch event for Visual Studio 2013 on November 13. It's not clear, at this point, if this will be a virtual event only or also an in-person one.

Topics: Software Development, Microsoft, Windows 8


Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Nice turn of events

    This appears to be the new standard: Announce something with obvious problems, then wait for the outcry, then address the outcry directly.
  • Near-Final

    Is that a new official Release designator? Release Candidate 1, Release Candidate 2, Near-Final Release Candidate... what's next Damn-Near-Final Release Candidate. or channeling Star Wars fighter pilot... Almost there, almost there Release Candidate (^L^)
    • not there yet...

      the naming will continue with:
      almost really there
      imminently there
      and so on ;)
      LlNUX Geek
      • not there yet

        "not there yet"
        "almost really there"
        "imminently there"

        I thought they were all descriptions of "the year of the Linux desktop"
        • There is only one (1)

          Description for the year of the linux desktop. "Never".
        • Don't worry, last year will be the year of Linux desktop.

          Oh wait, that was this year.
    • What is your problem?

      It is a release candidate. Google it :)
    • It's the Release Candidate build

      Which makes it the near-final build. It may even be the final build (hence the word "candidate" in the name).

      Generally at Microsoft, there's a daily build of Windows through most of the development phase. No one but folks in Windows sees these builds. One or two of those get declared "beta" builds and have wide release/distribution. Several others get wide internal release (to partner teams (think Office and Visual Studio), not to all employees). Eventually a "Release Candidate" is declared. Traditionally the Release Candidate got wide release as well. Finally, there's the "RTM" build that all of the various teams sign off on and from which all the release media is created.
    • what is wrong?

      What is wrong with the name Release candidate, it is used across the industry. I have never noticed companies releasing RC 1, RC 2 etc. As far as i know MSFT is releasing as they usually have been doing for years.
    • near-final??

      MJF add near-final in the title of the blog -- it's not the name of the product. Any RC is "near-final." I think you misread the title.
  • Silly comments

    Release candidate is a step in the software release life cycle. A release candidate (RC) is a beta version with potential to be a final product. There is a purpose for the name and the comments here are silly and useless. trying to look smart and witty.
    • Beta to RC to GM

      I think a Release Candidate is feature locked, only show-stopping bugs will be addressed. Betas may be incomplete and some of the features may be removed, if they or their dependencies are too broken to warrant prioritizing bug squashing by release date. GMs are it, what everyone will get (and then update to fix the bugs that shipped.) At some point debugging symbols are removed, I imagine between the last RC and the GM.

      I could be wrong though, I'm no release manager.
  • Visual Studio--Yet Another Fount Of Mediocrity In Windows

    Just been reading an article over in Ars Technica, pointing out how 3D and compute-intensive stuff works so much better on Linux than Windows, on the same hardware. Part of the reason is that Visual Studio generates such terrible code compared to open-source compilers like GCC. And Microsoft's standards support is pretty mediocre, too, like how far behind it is on C++11 support. I wonder if C/C++ standards guru Herb Sutter is embarrassed to be employed by Microsoft...
    • Um, what the heck are you talking about?

      Compilers don't generate code. They generate assemblies, or at the very least, bytecode.

      I know of no evidence that that the various C,C#, and VB.Net compilers generate assemblies of any significantly problematic nature.
      • Don't bother

        He doesn't bother with facts, he just cheerleads OSS while saying everything Microsoft does is wrong.
        Michael Alan Goff
      • Um, what the heck are *you* talking about?

        Compilers *do* generate code. C and C++ compilers generate machine code (binary). That's obviously what he's referring to. I often hear it referred to as just "generated code" all the time.
        That's unless you're compiling C++ to .NET, in which case, *wtf is wrong with you*?

        He's not wrong, though. Compilers do generate code. I can also testify that I get much better performance from gcc compiled C++ code than VS compiled C++ code, even if both are compiled and run on Windows (Linux is even faster).

        In the cases where you'll care about performance (i.e. the cases where you would bother using C++ instead of .NET or Python), Microsoft's compiler simply isn't as good as gcc. It's quite simple.

        Assemblies can refer to anything, although the majority of the time assemblies refer to .NET compiled code, specifically.
    • WHAT?

      Yes, Linux can run computational models quicker than in Windows but it's not because of VS. The result is usually due to the UI overhead in Windows. In Linux you can run headless and strip out much of the overhead not needed for the compute cluster.
      • Re: The result is usually due to the UI overhead in Windows.

        Only partly true. Even GUI apps run faster on Linux. E.g. Blender works better, does renders quicker etc.