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.
Hello Awdhes, I would like to understand issue reported by you better. It would be great if you can put me in touch with Microsoft Support professional who is handling your case. I can just talk to them and understand the issue. You can contact me on netfx45compat at Microsoft dot com.
I am not able to install .Net 4.5 in my laptop. My OS is Window 7.
Please help me?
@Rohit -- Contact us @ firstname.lastname@example.org
We have the pleasure of finding our .net4 project passed QA,. and behave inconsistently in the field with different .net combination on client machine.
Whose great idea is this "in place" upgrade? we need to isolate older release, and deal with each new ones separately.
RE: We have the pleasure of finding our .net4 project passed QA,. and behave inconsistently in the field with different .net combination on client machine.
Hello, I am from Microsoft .NET team. I would like to understand issue reported by you better. Could you contact us on netfx45compat at Microsoft dot com?
If MS really care about the compatibility, the scope must in its windows or office product business life cycle, otherwise, it will be killed. Although MS said .net 4.5 is an in-place update, still killed XP support. Each version of Visual studio will kill a older version of office development. Does anybody disagree?
Installed 4.5.1 (not by choice) on the build machine. Re-built our app. That app no longer runs on machines that do not have KB2858725 (4.5.1). This is especially bad because this app is required to run in factories that are still on XP, and 4.5.1 isn't available for XP (in spite of there being another month of support.
Note XP will be running in factories for a long, long time. I could take you places in China that are football fields sized rooms filled with machines running XP. We might not like it. But it's not an option to tell these places that XP is no longer supported. the only way to keep serving these machines is to freeze a version of VS2010 and make sure it never, ever gets updated.
@"XP No More", note that you could still build .NET 4.0 apps on your build machine with .NET 4.5.1. Just install .NET 4.0 reference assemblies on machine with .NET 4.5.1, and you could build apps for machines with .NET 4.0.
Here is link to installer for .NET 4.0 reference assemblies -> www.microsoft.com/.../details.aspx
We have a web.config that is for .Net 3.5.
When we set out App Pools to be .Net 4.0, our application breaks because it is looking for older assemblies. How can we regenerate the web.config entries so that all the assembly information references the correct version, and has the right PublicKeyToken?
Will .net 4.5 or .net 4.5.2 will work with VS 2010? Appreciate your detailed discussion
It is October 2014 and people are still struggling with incompatibilites and migration paths from VS2010/.NET4.0 to later versions of the development tool and framework. However if an updgrade to VS2012 (therefore .NET4.5) means that my apps will break and die just because a dev wants to work with the latest VS, then that is not acceptable and shouldn't have been possible in the first place.
This time Microsoft breached the main tenet of .Net, which was to guarantee backwards compatibility of the framework no matter which version your users were running, by creating an in-place update of 4.0 to 4.5. The decision was obviously not a technical one, because I can't believe a tech would be that incompetent to break many years of backwards compatibility in .Net and I can't believe hundred of apps that you supposedly tested did not show up any incompatibilities, only to have some people here raising their broken apps.
For the MS reps to be asking for more information and copies of projects at this late stage in the game just shows MS's contempt for the developer community and moreso for their millions of desktop users. It is laughable to see the reps on this forums ask for more information and being surprised that they haven't seen these problems in their own tests - what are your QA people doing then?
This silly decision for an in-place update of .Net 4.5 was either made to help large corporates avoid expensive .Net Framework upgrade releases OR to ensure WinXP apps and older .Net frameworks were forced into retirement by incompatibility problems, hence requiring new purchases of the latest OS and more $ for MS coffers.
There comes a point in a devs life where worrying about tools, OS compatibility issues and illogical framework design decision affecting their apps and spending more unpaid time helping Microsoft fix their blunders, is just not worth it anymore. The shop seems to be run by amateurs these days and the pro's seems to have jumped across to the big search engine guy or zucker's head office.
What is means for me is that most of my apps have now migrated to Android or PHP and the little I have remaining in .Net/Windows will soon be migrated to a webservice to avoid having my users install and upgrades to .Net and save me the trouble of tracking incompat issues for Microsoft. More time programming solutions, less time stuffing around with the over-engineered, highly complex and very fallible MS architecture. Goodbye MS, hello Android, I hope most developers learn their leson before they waste too much time like I have over the years putting up with backflips from MS, change of direction and compatibility nightmares. Sayanara.
@Mike: well put. It's really a pity but nowadays working with MS products like Visual Studio, NuGet and the various web frameworks has become more an exercise in patience and figuring out all the unexplained incompatibilities and non-deterministic behaviors that you would continuously come across and that developers simply should not have to worry about, in my opinion. The whole assembly versioning issue together with NuGet, which basically just makes it easier to make a mess because the mechanism is fundamentally flawed, is one such example, probably the worst. Teams I've worked with spend almost more time getting it to work than focusing on what they really need to do, and the worst thing about it is that it's become almost normal for people working with such products to have to spend so much time on such accidental complexities. Luckily for us there are quite some alternatives out there.
Bob: don't get me started on NuGet, I almost ditched that retarted tool the same day I tried to install it and spent 6 hours figuring out why it wouldn't do so with various cryptic errors. Then I realised all I needed to do was download HTMLAgilityPack and reference it manually, which took 5 minutes, but was made so difficult to find because library writers were hiding their libraries in NuGet repositories rather than making them available to us. If NuGet is MS's answer to Linux Repositories then MS have shown their incompetency yet again, everything is SO SO smooth in Linux. You can even run Windows within the WINE tool.
Year after year the MS headquarters show utter comptempt for their developers and are more worried about profitable decisions rather than helpful decisions, its an uphill battle just to finish our apps and get them distributed on the .net platform. If you're paid by the hour then you are happy, otherwise its a loss of your valuable time. MS capitulates to the corporate sector and decisions are made primarily to force corporate upgrades...oh we need the latest MS server to .NET framework because critical application A won't work on our current infrastructure, boom, instant revenue. Linux, Android, php, mysql etc are all accomodating of developers because they were built by developers and for developers, so there are no hidden interests. It's so good to work in such an environment for a change.