A first hand look from the .NET engineering teams
Updated – 8/16/2012: Added license information about the source code release.
Today, we are happy to announce the availability of Microsoft .NET Framework 4.5 and Visual Studio 2012. You can develop apps that will take advantage of all the great features that we have added, including new features in Windows 8. We are also announcing the availability of the .NET Framework 4.5 reference source code, under the Microsoft Reference Source License (MS-RSL).
You can read more about the Visual Studio 2012 release on Jason Zander’s blog and Soma’s blog. Please visit the Visual Studio 2012 downloads page to install both products.
We have made many improvements in the .NET Framework 4.5. Many of these advances help you write better apps with less effort, while others help you target particular Microsoft platforms. In either case, you’ll find the new features useful and relevant for the apps that you write today.
In addition to releasing the .NET Framework 4.5, we are pleased to announce that we are also releasing the source code for the .NET Framework libraries. We are releasing the source under the Microsoft Reference Source License (MS-RSL). While you may enjoy reading the many interesting algorithms in our product, we release the .NET Framework source primarily to improve your debugging experience. Having access to all the managed source for the code running in your process provides you with a lot more information about what your app is actually doing.
If you are new to developing with the .NET Framework, you may not know that we have released the source and rich symbols in past versions. We know that many developers rely on our source code to efficiently get to the root cause of functional and performance problems in their apps. As a result, we provide the source code concurrently with the release of .NET Framework 4.5.
This release includes the following:
We’ll now look at how you can use the source code and symbols.
You may be wondering what debugging with .NET Framework reference source looks like. In the example below, you will see a tool of mine calling the public Console.WriteLine method. From there, the WriteLine method calls several private managed APIs, and eventually ends with one or more platform invoke calls. You can see each of these calls in the Call Stack window. You can look at each call frame, both in terms of the source for that frame, and any locals that are available. That’s pretty useful!
This experience works for 32-bit and 64-bit apps on x86 and x64 machines, as appropriate. It also works when running on either an x86 or x64 machine, while remote debugging an app that is running on an ARM tablet. I can imagine that you might be looking forward to giving that last scenario a try.
This experience also works for all .NET Framework app types, including ASP.NET, WPF, Windows Forms, console, and Windows Store apps. We call this experience of seeing .NET Framework library source in Visual Studio, “.NET Framework source stepping.” As you might guess, you can step in and out of .NET Framework code, using all of the stepping commands that you are used to, such as F11, F10, and Shift+F11. It's pretty easy to set this up. I'll explain how.
We’ll first start with the instructions for enabling source and symbols download on demand. This mode works the best if you have consistent Internet access. You need to make a few configuration changes in Visual Studio 2012.
First, open the Options dialog box by choosing Options and Settings… from the Visual Studio Debug menu, expand the Debugging node, and then choose the General option. Set the following:
Next, set the following on the Symbols page which is also under the Debugging node:
You can now choose OK, and start using .NET Framework source stepping as part of your development process.
There are times when you don’t have a connection to the Internet, for example, when you're traveling. Also, some people prefer to pay the download cost just once, and then not think about it again. We’ve got both of those cases covered.
You can download the source and symbols for the .NET Framework 4.5 as an MSI installer. Once you've installed them to a particular location on your local disk or network, you need to provide a symbol file location that's different from what we've specified in the previous section. I’ve provided an example below.
Once you have the offline reference source package installed and configured (as shown above) in Visual Studio 2012, you are ready to start stepping into .NET Framework library source.
You can use the .NET Framework multi-targeting features and the reference source together; however, it is important to know how these relate to each other. The reference source is tied to the runtime version that you run your project on, not the version of the .NET Framework that you are targeting. For example, even if your project targets the .NET Framework 4, you will be using the .NET Framework 4.5 reference source when debugging in Visual Studio 2012.
We hope that you are as excited as we are about the release of the .NET Framework 4.5 and the reference source. We’ve built many new features that will make you more productive targeting all of the Microsoft platforms. You can download the .NET Framework 4.5 and Visual Studio 2012 from the Visual Studio downloads page.
You can learn more about reference source at the Microsoft Reference Source Code Center.
As always, we would like to hear from you. Please don’t hesitate to post a comment on the blog or at one of the forums that we monitor: Connect (report bugs), UserVoice (request features), and MSDN Forums (ask for help).
Congradulations! The file names and the version numbers on the download source page are really intuitive. What is .NET version 8 for example? And what is an FXUpdate version 5.something? And so on. I did not know that you had released .NET version 8. Seriously, is this a professionally done job or something done by a teenager in their free time? If you can't create web pages containing intuitive and correct language descriptions of your own products, then I can't imagine what the actual source will look like. Aren't you ashamed?
Plus, why should the source code be in an MSI? A normal zip would be so simple for Microsoft perhaps?
I am sorry but don't you understand that this is sloppyness in its fullest extend?
I downloaded the code and to my astonishment I could find no unit tests with it. Does this mean that they are simply excluded or is .NET not tested using unit tests at all. If the latter is the case, it would be unacceptable for a modern software company. Also, the comments in the source are sloppy and inconsistent; some use three slashes whilst others use two for no apparent reasin. Some documentation comment say "To be supplied" whatever that might mean. And the worst: all class field have an "m_" preppended. This is 2012 and not the 80s or the 90s. Plus, most source files have unnecessary usings at the top that are not really needed. Is development at Microsoft so sloppy?
Nico, I think you'll find the unit tests are simply omitted.
As for the sloppyness, some parts are simply irrelevant. Documentation headers are required, and I'd say that's a bad point on MS's behalf on the bits that say "to be supplied", but the thing about "m_" is not that big of a deal.
>> we're working on writing more details about compatibility.
I look forward to reading them. But I urge you to please consider making RUN TIME backwards compatibility (.NET 4.0) of new .NET 4.5 apps (that "target" .NET 4.0) a large part of you write up. (Meaning when I develop in Visual Studio 2012 but deploy to .NET 4.0 machines.)
There are three reasons this needs to be a large part of the writeup:
1. There are many write-ups about the "Target .NET 4.0" feature. But that is a COMPILE TIME feature. We need info on what is done for RUN TIME.
2. This information is critical to know for .NET 4.0 developers who may or may not be upgrading to Visual Studio 2012 (and by extension, .NET 4.5)
3. The current state seems to break the .NET premise (of mulit-machine support for .net applications). This is because of the example in my last comment (which I would really like to hear your opinion on).
I think the way the source code to the .NET Framework is provided needs improvement. IMHO, the source code should come bundled with either the .NET Framework, or with Visual Studio so that it works more like NetBeans in the Java world. My chief complaint to date is that you can't hit F12 to go to the definition of things when you aren't debugging. I.e. I think it should be easy to navigate through the source code while you aren't debugging as well as while you are. This is one area where I think Java is still ahead.
Are you still formulating a response to my comments? If you are still thinking it over, can you please post an "I'll get back to you" comment.
I am worried I have dropped into being ignored again...
@Stephen, not to worry -- you haven't fallen into the gap. We're working on it.
Hello, I have downloaded the 4.5 version from Reference Source Code Center to make it available offline as described in this post. However, Visual Studio still tries to download public symbols every time the debugging is started (tested with blank new console application too). Is there anyway to prevent it trying to download anything and just load what is downloaded? If I manually try to load the symbols from symbol path in Modules window, it also starts downloading. The Symbol Load Information does not show trying the path I have installed the symbols to.
Thanks for any hint!
@Brandon Bray - Looking at your new write up for .NET 4.5 Reflection, I can't help but feel that you have abandoned the discussion we were having about bug fixes being breaking changes.
You say that all bug fixes are not breaking changes. But you offer no examples of how that can be so.
I offered an example of a bug fix that (from my view) is clearly a breaking change. My arguments for it were clear and well laid out.
Please give me a response on this.
Is there anything in .NET 4.5 that assists in RUNTIME compatibility to .NET 4.0?
Or is there some logic that makes it so that I don't need to worry about accidentally using the fixed bugs when I write apps intended for .NET 4.0?
Please don't abandon the discussion we were having. This is critical to me and so many others who still need to support .NET 4.0 Apps.
@Brandon Bray - I check this blog most every day. Hoping that you will come through with some kind of explanation.
Please post something about the backwards compatibility for bugs.
Another day passes with no acknowledgement.
@Stephen, I haven't forgotten. I'm happy to hold a phone conversation or email conversation to address your most urgent issue while we continue to work on this topic. If you'd like to take me up on this, please send me an email via the purple "contact" icon at the top right of this blog.
@Brandon Bray -
My issue is not "urgent" from a business standpoint. (My business has already decreed that no developers can install .NET 4.5 because of "Fixed Bugs". I am hoping for some info that will reverse that decision.)
I apologize for being impatient. I guess I don't know how much work goes into one of your posts. (It has been 3 weeks since you said you were working on a writeup. I mistakenly assumed it would not take that long.)
I will try to be more patient. I will ping back in a month or so.
Hi Brandon Bray,
Our .Net development team at http://www.imensosoftware.com is really very excited about the release of the .NET Framework 4.5 and the reference sources. New features of .NET Framework 4.5 RTM are really great.
@Brandon: If I may attempt to further clarify the issue here:
4.5 is an in-place upgrade. This means that I cannot truly emulate the behaviour of running on 4.0 if I upgrade to VS2012. This means that bugs which exist in 4.0, but were then fixed in 4.5, are then non-reproduceable from my dev machine.
Couple this to the fact that 4.5 is not available for XP, and it creates a more serious problem. Customers may be experiencing effects of these 4.0 bugs by running my application on XP, which I am then unable to reproduce in my dev environment because I have 4.5 installed, even though my application is still *targetting* 4.0.
What we have is a perfect-storm of bad decisions. The in-place upgrade of a new version, plus the lack of support on an OS that's still extensively used in home and business environments makes for potential support nightmares for developers.