views:

392

answers:

3

I have a large .NET remoting project using the 2.0 framework. The server's API is exposed via interfaces and shared types are contained in an assembly shared with the client application.

I have some methods that accept arrays of a base class that has many different classes inheriting from it.

For example I have base class "Vehicle" that has two classes that inherit from it say "Car" and "Truck".

I have a method IFoo.Save(List vehicles)

Later on I add a new class that inherits from "Vehicle" named "Motorcycle", and only the server or client has the new shared assembly but not both. One of them won't be able to resolve the new type.

What do you feel is the most flexible way to handle this situation?

EDIT: This is a Windows forms client application and remoting server hosted in a Windows service.

+1  A: 

This seems like more of a deployment question. Server and client must have access to the same version of the shared assembly. Your strategy will depend on platform- is this web or forms?

One way to do this is to force clients to use a specific version of the shared assembly and provide a delivery method for that assembly to clients.

Dave Swersky
+2  A: 

Publish an update. For things like this you always have to have everything on the same version. Maybe consider ClickOnce to keep everyone up to date.

Matt Briggs
+1  A: 

ClickOnce is a good solution.

Or go with a class-agnostic Web Services approach. Pass around versioned, binary-streamed dictionaries that can be reconstituted as objects. If it is important, write your object reconstitution stuff to handle both forward- and backward-compatibility, otherwise just reject data with a "future" version number.

Web services are great for decoupling. Dictionaries are great for passing general data. Assembly-based class versioning is horrible (even with the Serialization changes in recent versions of .Net) and leads to madness...

Jeff Kotula