« Converting Visual Studio 2003 Web Projec...
Latest post
Naked Conversations »

Compatibility between 1.1 and 2.0 Framework

Sunday, May 14, 2006 6:00:00 AM (GMT Daylight Time, UTC+01:00)
Playing around with some of the .NET 2.0 framework and here are some interesting things to note.
 
IPC Channel
There is a new bidirectional IPC Channel (System.Runtime.Remoting.Channels.Ipc ) with the .NET Framework 2.0 that does not use the network layer when communicating between AppDomains.  This equates to increased performance for applications communicating between each other on the same machine.
 
BinaryFormatter/SoapFormatter and CLR Backward Compatibility
If you have a need to remote between the 1.1 and 2.0 versions of the .NET Framework and are using the BinaryFormatter, a patch will be required for the 1.1 framework, that will allow it to communicate with 2.0 (http://blogs.msdn.com/eugeneos/archive/2006/03/15/552315.aspx).  This is mostly do to the fact that minor changes (adding extra fields for example) to types serialized by the BinaryFormatter are considered breaking changes in 1.1.  It looks like with the introduction of the Version Tolerant Serialization ( http://msdn2.microsoft.com/en-us/library/ms229752.aspx) a similar patch will not be required to go from 2.0 to the next revision of the framework.  This patch is not applicable to the SOAP formatter, since the SoapFormatter implements a less stringent type checking which allows the addition of fields with out breaking serialization.  This would also indicate the importance of the SoapFormatter has been reduced and there would be very few benefits for using it over the BinaryFormatter and the introduction of Version Tolerant Serialization.
 
Serialization of Generics
The SoapFormatter does not support serialization of Generics, however the BinaryFormatter does. http://blogs.msdn.com/mattavis/archive/2004/08/23/219200.aspx  Another reason to move away from the SoapFormatter for .NET to .NET implementations.
 
CLR
Recently while working on a project for a client we discussed how upgrades were going to work for the application.  This eventually evolved into a discussion of how updates to the framework would come into play with the application.  These are my findings.  When I refer to 1.0, 1.1 or 2.0 I am referring to the version of the .NET Framework.
 
Using a newer version of the CLR to load assemblies compiled in older versions is generally OK, because of the .NET Frameworks commitment to being backwards compatible.  Instances can arise where the older implementation will fail to work, and those have been documented at: Breaking Changes from Version 1.1 to 2.0 (http://msdn.microsoft.com/netframework/programming/breakingchanges/default.aspx). 
 
Currently I am using the July 2005 Application Blocks compiled in 1.1 with the .NET 2.0 implementation without a problem.
 
Loading Assembly Changes
It is possible to load a 1.1 assembly into a 1.0 application.  It is also important to note that the 2.0 CLR will not allow you to load an assembly built with 2.0 into a process that is running the 1.0 or 1.1 .NET Frameworks
 
Framework Resolution
It is possible to run an application compiled for the 2.0 Framework, and have that application consume assemblies built in 1.0,1.1 and 2.0.  The important thing to understand is that the process will redirect all references to the version of the CLR that is loaded into the process.  This allows types to be shared among all the different versions of the assemblies.  For example, a reference to a System.Xml.XmlDocument in .NET Framework version 1.1 can be consumed by .Net 2.0 application with out any problems.  Since it is possible that there may be undiscovered issues with this default behavior of the CLR you can override this capability in the configuration file and tell the 1.1 assembly to bind to the 1.1 version of System.Xml.XmlDocument.  However, if you try to communicate with any other assemblies that were not compiled in the 1.1 framework the CLR will throw an exception.
 
Some interesting links related to  framework capatibility.
 
CLR 2.0 Compatibility and Side by Side (Brad Abrams Blog)
 
Targeting a .NET Framework Version
 
 

Posted in Development |Comments [0]     

Comments are closed.