How do objects of C# classes handle backwards compatibility?

[eugen_nw]

Hi all,


I'm new in dealing with backward compatibility issues and want to make
sure that there aren't some hidden aspects of this problem that I am
not aware about.

The problem I'm having is that in version 2.1 of the framework that
I'm working on I need to add some new properties to classes that
shipped in previous versions. The desired outcome is that clients
that have used previous releases of our framework do not need to
recompile in order to use the upcoming version 2.1. If the objects in
question will never be serialized/deserialized by the client
applications, is there any other way that clients of earlier versions
of this framework will run into problems if I extend some classes? I
did some experiments with this and saw no issues, although the
scenario I've tried was fairly simple: the client was calling the
constructors in the framework and was using pre-existing properties of
the object the framework returned. So no enumeration of public
properties through reflection and throwing an exception if the number
of public properties is not a prime number

Did anyone run into any weird backwards compatibility scenarios that
one should rather know earlier than later?


Thank you, eugen

 

[andy.johnstone]

Hi all,

I'm new in dealing with backward compatibility issues and want to make
sure that there aren't some hidden aspects of this problem that I am
not aware about.

The problem I'm having is that in version 2.1 of the framework that
I'm working on I need to add some new properties to classes that
shipped in previous versions.  The desired outcome is that clients
that have used previous releases of our framework do not need to
recompile in order to use the upcoming version 2.1.  If the objects in
question will never be serialized/deserialized by the client
applications, is there any other way that clients of earlier versions
of this framework will run into problems if I extend some classes?  I
did some experiments with this and saw no issues, although the
scenario I've tried was fairly simple: the client was calling the
constructors in the framework and was using pre-existing properties of
the object the framework returned.  So no enumeration of public
properties through reflection and throwing an exception if the number
of public properties is not a prime number

Did anyone run into any weird backwards compatibility scenarios that
one should rather know earlier than later?

Thank you,  eugen

That's really what side by side versioning and private assemblies
(that is, they are installed with your application, not shared on a
machine) is supposed to address. If your assemblies are strongly
named, it will refuse to use the newest version. If not, which I
suspect is what you've tested, it may be fine...

Is there a reason to install a new version into an application without
updating the application exe itself? Or are you installing the
assembly into the GAC?

 

[Pavel Minaev]

The problem I'm having is that in version 2.1 of the framework that
I'm working on I need to add some new properties to classes that
shipped in previous versions.  The desired outcome is that clients
that have used previous releases of our framework do not need to
recompile in order to use the upcoming version 2.1.  If the objects in
question will never be serialized/deserialized by the client
applications, is there any other way that clients of earlier versions
of this framework will run into problems if I extend some classes?

Unlike Java, where adding new members to non-final classes, C# is much
more safe in that regard. In general, short of reflection (which is
"by design") and serialization (which can be versioned separately -
check MSDN for details), clients compiled for older versions will
continue to work for your scenario. C# was specifically designed with
such versioning issues in mind - if you're interested in the
background, have a look at this:

http://www.artima.com/intv/nonvirtual.html