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.
What's the best way to call attention to issues in .Net 4.0 that are not fixed yet in .Net 4.5?
Specifically there's still no way to get the difference between the requested and actual offsets in use by the MemoryMappedFile API: connect.microsoft.com/.../537635
I'm confused. Is this equivalent to the way .NET 3.0 and 3.5 were additive releases on top of .NET 2.0, or is this something new?
I hate it when you guys lie about versions like this.
1. How would an app detect the *actual* version of .NET? Say, to attach to an automated bug report. 4.5 will have APIs that aren't in 4.0, so it would sometimes be important to know which version a client is actually running, and you're going to make that difficult if you deliberately lie about the version.
2. Will there be any way to tell Visual Studio that I actually want this project to target .NET 4.0, thankyouverymuch, and please give me a compiler error if I try to call something from 4.5? 'Cause if 4.5 lies and says it's 4.0, it would be all too easy for me to write a "4.0" app that calls something from one of the "4.0" assemblies, but that won't actually exist on a client's really-truly-4.0 machine. (The same problem exists when you add APIs in service packs, and it's a nightmare then too.)
Agreed with Joe. I understand that you want people to upgrade to 4.5 and not worry about compatibility, but for those of us who will have 4.5 on our dev machines to play around with and no control over whether or not 4.5 gets put on the client machines, it's not very fun.
So .net 4.5 will support XP and vista? That kinda is the big question.
@wcoenen: Yes, 4.5 is to 4.0 in the same way that 3.5 relates to 3.0 and 2.0. Joshua covers it a bit more at the beginning of his What’s new in .NET 4.5 talk: channel9.msdn.com/.../TOOL-834T
@Joe White, @Spivonious: the way to target .NET 4 in Visual Studio 11 by using targeting packs. It works the same way as targeting .NET 3.5 from VS11 or VS2010. Scott Guthrie shows how this works here: weblogs.asp.net/.../multi-targeting-support-vs-2010-and-net-4-series.aspx
Great, because 3.5 worked so well! :(
What are you doing to address this case: A new API is added in 4.5 to an existing assembly, an app is built against this API and then run on a 4.0 CLR??
In 3.5, the app worked for the most part then crashed horribly, the example being an overload added to EventWaitHandle.WaitOne() which was not in 2.0.
You never learn.
And multitargeting was designed to prevent exactly that.
After installing 4.5 some of the programs I use that are 4.0 reliant broke:(
@JJ Murphy: I'm sorry to hear that your program broke. We need this feedback to ensure the final release of .NET 4.5 is compatible. Please make sure to tell us what broke (via Connect) so we know what to fix.
Is Microsoft listening to the feedback?
If you would just let 4.0 and 4.5 co-exist on the same machine as separate runtimes, then you could not break 4.0 applications.
@Brian: I'll work on getting a discussion going about side-by-side vs. in-place releases. There's more to consider than just compatibility. And I can assure you, the comments left here are being read and discussed amongst the teams contributing to .NET.
Please, please listen to what Michael K. Campbell has to say on www.devproconnections.com/.../net-framework
If they're 100% compatible then do a in-place upgrade, but don't call it 4.5. If you make breaking changes you can NOT guarantee compatibility. When I write something against version X then I want the guarantee that it would work the same years from now -- as long as the underlying OS is supported. If installing 4.5, because some other app needs it, breaks 4.0 apps then the whole proposition goes out the window. We would now have to worry about checking old apps, for which we may not have the source to or the man power to retest in 4.5
To even consider this is so asinine that I would personally fire the person who even thought this would be a good idea.
What do you mean by "compatibility"?
You have added new types (TypeInfo, for example) and other types moved in other assemblies. This is a breaking change! And this is done without changing of the Framework version!
My projects no longer be compiled after installation of VS 11.