A first hand look from the .NET engineering teams
Fundamentals were a big part of our focus while building .NET 4.5. We divided fundamentals into seven areas called “tenets”. One of these tenets is compatibility. Today’s post is by Manish Agnihotri, a program manager who is driving compatibility across the .NET Framework. -- Brandon Editor's update: we've added more discussion about the compatibility of .NET Framework 4.5 in a recent post on October 17, 2012.
Fundamentals were a big part of our focus while building .NET 4.5. We divided fundamentals into seven areas called “tenets”. One of these tenets is compatibility. Today’s post is by Manish Agnihotri, a program manager who is driving compatibility across the .NET Framework. -- Brandon
Editor's update: we've added more discussion about the compatibility of .NET Framework 4.5 in a recent post on October 17, 2012.
.NET Framework 4.5 is an in-place update that replaces .NET Framework 4 (rather than a side-by-side installation). Our goal is for .NET 4.5 to be fully backward compatible with applications built for .NET 4 (.NET 3.5 and .NET 4.5 will be side-by-side). We’ll talk about the compatibility story for .NET 3.5 in a later post. One of the first things you’ll notice about .NET 4.5 is the version number (4.0.30319) is the same as .NET 4; this is the practice used by other in-place updates.
Our primary concern is guaranteeing applications you use do not break after you install .NET 4.5. We accomplish this by running hundreds of application in our compatibility lab to find issues as soon as they’re introduced. While designing new features or changing existing code, we keep compatibility in mind. And a small group of us, the Developer Division Compatibility Council (DDCC), monitor changes made by developers. We review potential breaking changes, and help teams understand and assess the compatibility impact of new features and bug fixes. For .NET 4.5, members of DDCC reviewed every proposed breaking change, every new feature, and a majority of the bug fixes for the release.
We’ve put a lot of effort into maintaining a consistently high bar for compatibility across the product, yet we know some issues may get past us. Many applications will exercise the .NET Framework in ways that we did not expect or we lack test coverage for. Still we care about knowing every issue, even those that may seem like corner cases. Once you install .NET 4.5 Developer Preview on a machine that previously had .NET 4, any compatibility issues can be sent to the Connect feedback site.
There are three kinds of version compatibility testing we do: (1) binary compatibility, (2) source compatibility, and (3) serialization compatibility. You may also find these approaches useful in your testing, and should an issue arise this may help you narrow down the root cause. Having a wide range of scenarios within each kind of tests is also critical to ensuring good compatibility coverage.
Binary compatibility uses binaries built targeting .NET 4 and then are run on .NET 4.5. Essentially, we’re testing that the behavior of newer .NET libraries is equivalent to previous versions. This can range from making sure the return value of a function is the same or that the same exceptions are raised. The hardest issues are multi-threading behaviors – sometimes performance improvements can be a breaking change.
Source compatibility takes an application that builds and runs successfully against .NET 4 then does the same with .NET 4.5. An interesting case is a machine where Visual Studio 2010 runs on a machine with .NET 4.5 installed – since reference assemblies are used for targeting versions of the framework, building an app in VS2010 and then running it is actually binary compatibility testing. To do source compatibility testing, we build against the .NET 4.5 targeting pack (which is part of the Visual Studio 11 Developer Preview).
Serialization compatibility deals with data and has several permutations. First, we let an app running on .NET 4 serialize data (e.g. save to disk) and then an app running on .NET 4.5 de-serializes (e.g. read from disk). Second, we do this in reverse by serializing from .NET 4.5 apps and de-serialize in .NET 4 apps. Third, we take a web service running on .NET 4.5 reading serialized data created by a .NET 4 based client. Fourth and last, we do the inverse with a .NET 4 web service and a .NET 4.5 client. A serialization problem will often show up as corrupted data or some kind of serialization exception.
Compatibility is an important part of migrating apps forward, though in rare cases it is necessary for a framework library to make breaking changes. We try to avoid this, using it as a last resort. MSDN documents the known breaking changes in .NET 4.5. We also have a migration guide with advice for testing your app.
If you discover any compatibility issues while working with previews and betas, we want to hear about them via Connect. Hopefully, all our work to make this a highly compatible release makes it easy for you to upgrade to .NET 4.5.
@VladD2 Are you creating a Metro style app? The new profile for Metro Style apps is not fully backward compatible. Krzysztof’s talk channel9.msdn.com/.../TOOL-930C explains more about the difference with the profile for Metro style apps. When creating a classic Desktop app with .NET 4.5, the functionality related to TypeInfo/GetType should be compatible. If the latter is breaking it would be helpful for us to have more information through connect so we can figure out the issue.
My msbuild tasks no longer work, so it's back to 4.0 (the real one) for me.
@Cb: Did you file this as a bug via Connect (connect.microsoft.com/visualstudio)? We of course want to know when something like MSBuild is broken so it can be fixed.
This seems to break the ability to do .net framework source stepping on framework 4.0 apps (at least with vs 2010 and vs 11 preview installed)
Who, exactly, is the inplace update system supposed to help?
It's not the server admins. Now they can't run one website for 4.5 without forcing every other 4.0 site hosted on the same server to be upgraded to 4.5.
It's not the developers. Now if they want to upgrade one website to 4.5, a website that might be using an incompatible 4.0 library that they don't have access to, they have to wait until the third party developer updates and patches the problem.
It's not the clients. Now if they want to upgrade their system to 4.5 because one application requires it, they risk breaking other existing installs that haven't been updated to work with 4.5. Not only that, they risk having to wait for the developers above to wait for other developers to release proper 4.5 versions before they can release their own fixes.
None of these things would be a problem if 4.5 could live side by side with 4.0. Server admins won't have to risk their hosted sites going down because one site requires 4.5. Developers won't have to sit and wonder if their apps will work because they can't tell if the client machine has the right framework. End users won't have to risk breaking any of their existing applications just to upgrade one app.
It seems like this inplace update system is supposed to make things "easy" for people who might be non-technical. And hell, inplace updates make sense if we're talking about something like Chrome updating transparently for the end user. But this is a huge framework that tons of applications rely on to be consistent. If you're a developer or a server admin, you shouldn't be afraid of having to change a version number in a config file somewhere. And an end user isn't gonna care either way, they have to run an installer for the framework no matter what you do.
@Manish and @Brandon: Didn't knew it till now that .NET 4.5 is an inplace update replacing .NET 4.0.
All the post and comments talk about the issues that may/have arised.
Can you please let us know, why did Microsoft decide to make this an inplace update.
.NET 3.0, 3.5 were built on top of .NET 2.0, but still they were side by side installation.
Again .NET 4.0 was a fresh release, but why is that .NET 4.5 turned into an inplace release when it could be an side by side release.
I believe in Microsoft. You have made such an awesome product and working so hard and rapidly.
I believe there should be a strong reason behind this decision. If you could share it with us.
Thanks & Regards
Arun Kumar Allu.
So version 4.5 is correctly named, but version 3.5 isn't? Now it's getting interesting.
Hello Brandon, thanks for the post. I'm frankly very concerned about the choice you have made to make .NET 4.5 an in-place upgrade to 4.0.
As mentioned by someone else already Michael depicts two very plausible horror-scenarios in his article here http://bit.ly/zzYn5E. I'm confident you have considered them, and it would be really useful to know why you still thought they didn't justify a different choice from you.
This was a brain-dead idea. Source stepping is indeed broken when you install .NET 4.5 over 4.0.
@Richard: this is a known issue in the Beta release of .NET 4.5. We're working to address this for RTM.
Installing the VS11 Beta caused my .Net Framework 4 WPF app (which still compiles) to start having strange SelectedItem issues with a ListBox (that does NOT have duplicates) and Groups / CollectionViewSource.
Uninstalling now....Fingers crossed that my machine won't be completely trashed.
Same for the utilities which ship with HP PCs and laptops. Install .NET 4.5 beta and they stop working. Not something you'll like to see happening on your brand new gadget.
@Berney, we really need to have more details in order to investigate the WPF issue you mention. We're looking at every issue. Can you submit a bug report through Connect? connect.microsoft.com/VisualStudio
Visual Studio 2011 beta Installed .Net Framework 4.5 which removed .Net Framework 4.0.
Programs built with .Net 4.0 subsequently would not run. In order to get .Net 4.0 back,lly had to uninstall VS2011. VS2010 had to be reinstalled along with SP1. I have to say that VS2011 is not ready for testing side by side with VS2010.