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.
@Kamran A, can you give us more specifics about the behavior issue you're raising with VS2010? The scenario you're talking about is one that we've done testing around and would like to understand. If you need to contact us in email, send mail to firstname.lastname@example.org.
Some of the grids in our applications got shifted and crunched all the way to the right. The grids are in a Table Layout Panel within another Table Layout Panel. Now that we see this issue in the screens, we cannot just upgrade our servers because our applications share the same servers. Even if we fix one if the application for the grid issue with the in place upgrade we will have to test the entire portfolio of applications. How do I know if a calculation might have gotten impacted which could cause my company to lose millions of dollars? We never had to face this before. This is not the best of situation
@Kamran A, we do want to investigate the issue you're raising, and we'll follow up with the WinForms team. A bit more information would be useful, so I'll invite you to email us at email@example.com to allow follow up questions.
I have sent details on the screens to the email address with my contact info.
I experienced an issue after installing VS2012 and .Net 4.5 because of this in-place upgrade.
Even though my app still targets the .Net Framework 4 and not 4.5, I was able to use MEF to export using generics, which was added in 4.5. This compiles and runs on a machine with 4.5. It compiles on a machine with 4.0 but fails at runtime. This lead to me deploying code to users that only runs on my machine since they do not have 4.5 yet. They get a runtime error since the part could not be found. I would have expected that if I target 4.0 that I cannot make use of 4.5 features and would get a compiler error or at least the same runtime error that my users and other devs on 4.0 get.
I opened a bug in connect: connect.microsoft.com/.../in-place-upgrade-breaks-backward-compatibility
Can I still use VS2010 Sp1 to develop .Net 4.0 apps when I install .net 4.5 on the dev machine?
After .NET Framework 4.5 is installed, you can continue to use VS2010 SP1 to develop .NET 4.0 apps.
The Visual Studio multi-targeting feature constraints .NET4.0 projects to only use .NET4.0 APIs (Even though .NET4.5 is installed on the machine)
If you have any feedback, you can always contact us on netfx45compat at Microsoft dot com.
I just recently moved from VS 2012RC up to VS 2012RTM. As I did this the version of .net changed also. Suddenly all through my active projects I am seeing the following error;
"System.Security.VerificationException: Operation could destabilize the runtime."
I have been working like crazy to put in place some workarounds, but many of the problems seem to be in dependencies of my project and I have no access to their internals for a fix. This situation is #%$@! miserable and I have a tight deadline to deal with. I can't seem to even roll back without a huge amount of effort.
Whoever let that bug through should be fired and this migration path you are using is a mess. Don't EVER overwrite a previous version of an assembly like that with breaking changes. What were you thinking?
Thank you for your feedback. We are aware of this issue and working on a update to address it. Could you email us at netfx45compat at Microsoft dot com to discuss? (we would like to triple check that your issue is 100% similar to what we are addressing).
.NET Framework Compatibility Team
Framework 4.5 isn´t FULLY backward compatible with 4.0.
Here I´ve posted a little backward compatiblity issue in WPF. It´s not a great deal, but we have expense several hours with it, and caused some troubles in our production systems.: stackoverflow.com/.../wpf-datagrid-changes-its-behavoiurs-after-installing-vs-2012
This change is not one of the expected WPF changes. At leats, it´s not here: msdn.microsoft.com/.../hh367887(v=VS.110).aspx
RE: Framework 4.5 isn´t FULLY backward compatible with 4.0.
I'd like to help take a look. Could you contact me on netfx45compat at Microsoft dot com with code sample? If you have already posted on connect, just email us connect link.
My Application is in .Net 4.0(VS2010), I need to run this on .Net framework 2.0 in another machine, How is possible?, without install framework 4.0 in another machine
@Abhijeet Parihar, in order to run your app on .NET Framework 2.0, you need to change the app's target framework from .NET 4.0 to .NET 2.0. Go here for details: msdn.microsoft.com/.../bb398202(VS.100).aspx
As a .NET developer this is really sad.
*I upgraded my computer to .NET 4.5* not expecting my *.NET 4 targeted web-app* to break. And how does it break? I fails to compile a little html TBODY tag. Seriously!?
Maybe us developers should start getting paid for the QA work we're doing for Microsoft.
Win7 SP1; VS2010 SP1 (.NET 4.5)
Losing faith in Microsoft..
@Omar, it would help us if you could send any details about the breaking change you've discovered to firstname.lastname@example.org. Based on the information you've given, this is not something we've observed before (and we know plenty of ASP.NET websites are working). So anything you can share to help us understand the issue will be much appreciated.