Black is white in Longhorn compatibility land
.NET Framework shenanigans
Microsoft has visited the Bizzaro World of application compatibility to explain which software will break once Longhorn's .NET Framework 2.0 is unleashed on Windows.
And the answer shouldn't be too surprising: applications written for the new stuff, in this case .NET Framework 2.0, are unlikely to run on the older stuff - that is, versions of Windows running the .NET Framework 1.0 like Windows Server 2003.
Customers will need either Longhorn or up-coming Windows Server Release 2 which will run .NET Framework 2.0, to use applications that are written for the .NET Framework 2.0.
Add-ins, such as those used in Office, are expected to pose the biggest compatibility problem, as these will default to the .NET Framework 2.0 in the Longhorn "wave" of products.
The good news? Applications written for .NET Framework 2.0 - particularly managed executables and those running on a pre-configured host - stand a better chance of running on more recent versions of the .NET Framework version 1.1.
This clarity has been provided by Microsoft engineers who have been diving into the application compatibility maze. In a broadcast on the company's Channel 9 blog service, Microsoft has attempted to clear up the growing confusion over how far existing Windows applications will be compatible with Longhorn.
It's a complex subject. First, you need to understand that backwards and forwards compatibility operate in the opposite direction.
Backwards compatibility is the ability for an application written on the .NET Framework 1.1 or 1.0 to run on later versions of the .NET Framework, like 2.0. Forwards compatibility is the ability for an application written on the newer .NET Framework 2.0 to run on older versions of the .NET Framework - 1.0 or 1.1.
Microsoft has decided to make the .NET Framework 2.0 the default for add-in applications, like the Newsgator content aggregator that runs in Microsoft's Outlook client, in order to be able to run previous versions of applications and documents.
However, compatibility between version 2.0 and version 1.0 is "unlikely", according to Microsoft's engineers, because of the huge amount of changes that have taken place between these two different versions of the .NET Framework.
That's a fact that could make it difficult to run the new versions of Office on older operating systems - one popular trick - or to write new applications for the Longhorn edition of Office that are also capable of working on the huge install base of existing Office users, without ISVs also writing their add-in for the .NET Framework 1.0.
Customers running applications for versions 1.1 and 2.0 of the .NET Framework on a machine running .NET Framework 1.0, meanwhile, will get an error message and be asked to visit the Microsoft website to download newer versions of the framework.
Reasons for conflicts between the different .NET Frameworks come about as Microsoft introduces so-called "breaking changes", which can effect the way applications run. Breaking changes occur when Microsoft introduces new security features, updates standards compliance or - as with Longhorn - uses longer version strings to identify the operating system's build numbers.
Microsoft is currently testing 200 applications, monitoring their installation and run-time behavior in 32-bit and - if available - 64-bit mode. The company is inviting ISVs who want to find out more about testing to email it at email@example.com. ISVs are also being encouraged to attend two compatibility test days in June and July in Redmond, Washington. ®
Sponsored: DevOps and continuous delivery