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 .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 passed 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.
Types of compatibility issuesThere 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. Read more: .NET Blog
QR:
Types of compatibility issuesThere 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. Read more: .NET Blog
QR: