Recent changes to the .NET Frameworks can provide developers with the tools and best practices they need to make supporting a new version of a framework easier.

In a blog post written by Mike Rousos, a software engineer on the .NET team, he said that beginning with.NET Framework 4.0, all versions with a major version of 4.x install as in-place updates. This means that only one 4.x .NET Framework will be installed on a computer at a time, he wrote. Developers should test their apps on any versions of the .NET Framework that they are expected to run on, since there might be some changes between 4.x versions of the frameworks.

Functionality and compatibility are both concerns when updating the .NET Framework. Sometimes, compatibility issues occur unintentionally, and that is why the .NET Framework team has to address these changes with a solution known as “quirking,” said Rousos.

“Quirking refers to the compatibility issue mitigation of having two separate code paths in the .NET Framework and choosing which path to take based on the .NET Framework version that the application is targeting,” he wrote. “Because many .NET Framework compatibility issues are mitigated in this way, it’s possible to avoid many potential issues when running on newer .NET Framework versions by leaving the targeted .NET Framework version unchanged for an app.”

Developers can override quirking behavior by using application or machine configuration settings, and because of some technical limitations and security risks, not all compatibility issues can be quirked. Developers can also enable or disable individual compatibility quirks by setting compatibility switches to explicitly opt in or out of compatibility-affecting changes.

Since some compatibility issues cannot be avoided, Rousos recommended these best practices to developers so they can continue to keep their applications running on new versions of the .NET Framework:

  • Unless necessary, do not retarget existing projects to newer .NET Framework versions. This will minimize compatibility issues, he said.
  • If possible, use newer .NET Framework versions instead of older ones. Many compatibility issues in 4.x versions of the .NET Framework have been fixed in subsequent versions.
  • Test if an app is rebuilt using newer compilers. This could expose it to compiler compatibility issues (though these are rare, said Rousos).
  • Use compatibility tools like the API Portability Analyzer and .NET Framework Compatibility analyzers to identify potential problem areas.
  • Test an app on any .NET Framework version it is expected to run on.