A first hand look from the .NET engineering teams
Updated (July 2015): See Announcing .NET Framework 4.6 to read about the latest version of the NET Framework.
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).
How does one upgrade from .NET 4.5 RC to .NET 4.5 RTM. It says 4.5 is already installed and won't upgrade.
@Craig I bet just uninstalling the RC then install will do it
Before you upgrade to .NET 4.5 (required by Visual Studio 2012), make sure that you don't need to support any .NET 4.0 clients (especally Windows XP ones).
Any bugs that are in .NET 4.0 will be hidden from your debugger after you upgrade.
See here for more info:
Which OS are you on?
If you are trying to install .NET 4.5 RTM on Windows 8 RC or earlier, you could get this message.
If you are not using Windows 8, we would like to understand the issue better. Can you grab the logs per the instructions below and share the same?
1. Download and run this diagnostic tool from here: go.microsoft.com/fwlink
2. Share the log generated by this tool: %temp%\vslogs.cab (using skydrive or equivalent)
Does the source download still have the files scattered in directories 10-15 deep, and with file contents duplicated within the same file (like someone copy/pasted the entire file twice into a new file)?
@Stephen, I've read through the forum thread that you linked through. We're still unaware of any specific compatibility issues that you're raising. The general concern about "bug fixes" should keep in mind that a bug fix that changes behavior needs to be done in a compatible way. To that end, .NET 4.5 is much like a service pack that also includes new features. We would love to know of any compatibility issues you've found so we can investigate them. If you have anything, feel free to email email@example.com.
Funny thing is, that when I click on download framework source, chrome starts to download aspx page. If anybody faces the same problem, the actual file type is msi.
yes, downloading in google chrome is a problem. I tried IE, works fine.
The breaking changes notes for 4.5 at msdn.microsoft.com/.../hh367887.aspx mention changes in SynchronizationContext.Current for WinForms but don't go into detail. For a simple WinForms application the WinFormsSynchronizationContext still seems to be installed by default. Anyone got further info on that one?
Change: In the .NET Framework 4.5, Windows Forms no longer overrides a null synchronization context.
Impact: This change may break an application that assumes that the synchronization context is always non-null.
I'll just wait until SP1. Like I always do.
@Jonas: believe it or not, file contents are still doubled for 4.5! I'v just opened the Connect issue #758459, hoping this will be fixed finally. So feel free to vote for it: connect.microsoft.com/.../net-framework-4-5-reference-sources-files-content-appears-doubled-when-installed-locally-from-http-referencesource-microsoft-com-netframework-aspx
By the way, the previous issue regarding 4.0 sources earned about 90 votes so far with no efect at all:
The discussion in the forum regarding 4.0 SP1 is now over a year old and reached over 15,000 views:
NOBODY CARES, obviously...
First, thank you for responding to my post. I look forward to a response to this post.
Let me try to address your comments:
>>We're still unaware of any specific compatibility issues that you're raising.
That is because this is a whole CATEGORY of compatibility issues. Every single .NET 4.0 bug that is fixed in .NET 4.5 is a compatibility issue.
Here is the reason why:
Once a developer installs .NET 4.5 those bugs are fixed on his dev machine. (And there is no list of fixes, so he does not even know what they are.) When he uses those fixes they are not compatible with any machine running .NET 4.0.
So his code is now compatible with .NET 4.5 machines ONLY! It will break on .NET 4.0 machines (and worse, the developer does not even know it).
>>The general concern about "bug fixes" should keep in mind that a bug fix that changes behavior needs to be done in a compatible way. To that end, .NET 4.5 is much like a service pack that also includes new features.
I would agree whole heatedly with this statement, if .NET 4.5 supported all the platforms that .NET 4.0 does. Then you can just require your users to all upgrade and be done.
But since it does not, bug fixes are backwards breaking changes. Developers will not see them, but platforms that do not (or cannot) have the "Service Pack" will. It cannot be thought of as a service pack because it is not backwards compatible with all platforms of the original release.
The platforms unsupported by .NET 4.5 still hold a full QUARTER of the market in the USA. That is a lot of incompatible computers.
The last part of my comment was not intended to be a "Support XP" comment.
It was intended to say, you chose to not support some Operating Systems, so the "Service Pack" argument cannot apply.
@Stephen, we're working on writing more details about compatibility. This is an area where we expend a lot of energy because we know how important it is to developers and moreover end-users. There are plenty of tradeoffs and we err on the side of making sure we don't break. To that end, we employ many strategies to accomplish that. We'll go into that shortly, but for now just a few remarks to your questions.
>>Every single .NET 4.0 bug that is fixed in .NET 4.5 is a compatibility issue.
This is not correct. A bug fix that introduces a behavioral change that is incompatible is considered a breaking change (which again we err on the side of not doing). Categorically, if there is a bug fix that introduces a breaking change and it's not documented on the breaking change list (msdn.microsoft.com/.../hh367887(v=VS.110).aspx), then we want to know about it. We do a lot of testing to ensure that this doesn't happen, and we know we're likely to miss a few cases -- that's why any issues should be reported to firstname.lastname@example.org. We'll take action on every issue.
Our goal is to make .NET 4.5 a compatible replacement for .NET 4. And that means using .NET 4.5 as a run-time while targeting .NET 4 should work and we intend to make it work.
First let me say, thank you for your response. It is fantastic to talk to someone about this issue.
>>A bug fix that introduces a behavioral change that is incompatible is considered a breaking change
I think we may not be matching up on what is considered "incompatible".
To try and align our definitions, lets use an example of this bug:
This bug is broken in .NET 4.0 and fixed in .NET 4.5.
That means that when a WPF developer takes an empty collection and Groups, Sorts and Binds it using Visual Studio 2012 (.NET 4.5) it will work fine, but when his app is run on a .NET 4.0 machine, it will break.
Is that considered a "behavioral change that is incompatible"?
If so then I have this questions:
• Is it (and others like it) documented somewhere?
If it is not a "behavioral change that is incompatible" then my question is "Why Not?"
Without a list of backwards breaking changes like this, I cannot know that I will not be releasing an app that relies on several of these backwards breaking changes/bug fixes.
(And even with the list, I fear that it would be so huge as to overwhelm my QA team.)