CSLA remoting and assembly version conflicts

sune42 posted on Wednesday, September 06, 2006

Hi

Just a theoretical question, what will happen if the my CSLA business object assembly version on the remoting server is slightly different than the winform client?

(I mean using the exact same CSLA framework version,  but my custom business objects assembly might be slightly of out date).

I mean some users might not be using the exactly latest version.

So, what happens? will CSLA break and just stop? or will it still function if the methods signatures/names are the same? or are they using some checksum to make sure the CSLA objects are the same?

Perhaps we should have a way in the client to "check/test" if the assemblies are compatible/same on both ends?

//andy

 

ajj3085 replied on Wednesday, September 06, 2006

Your remoting host will fail to process, because type information is serialized into the remoting stream, and when IIS can't find the correct version, boom!

I have code on my application startup that forces my users to always connect with the latest version; if not, the program tells them to update and try again.

MartinMason replied on Wednesday, September 06, 2006

Seems to be an argument for installing CSLA in the GAC. 

ajj3085 replied on Wednesday, September 06, 2006

Well, I think the OP said it was his business assembly, not Csla that may be 'out of sync.'

Of course the larger issue is should users be able to use outdated business assemblies to connect.  It depends on the changes to the assembly though and user requirements. 

In general, you should not install assemblies in the GAC.  The GAC is supposed to be for the .Net framework, or assemblies which should act as part of the .Net framework itself.  At least I've read quite a few articles stating that.

MartinMason replied on Monday, September 11, 2006

ajj3085 raises a point that should probably be discussed.  The GAC is a place to store reusuable, shared assemblies.  If your organization is building nTier applications with CSLA and CSLA is providing the entire enterprise plumbing backbone, wouldn't it make sense to install CSLA in the GAC?  Really, wouldn't the CSLA namespace become as critical to your code as System?

Installing CSLA in the GAC also allows for side-by-side existence of different versions of the same assembly.  When compiling assembly references from the GAC, the version stamping of the referenced assembly is included in your assembly manifest.  (You can always use an application configuration file to override the version)  You cannot obtain these benefits with private assemblies.

ajj3085 replied on Tuesday, September 12, 2006

I guess it depends on how you define 'extend the framework.'  Certainly one way is the way you describe.  I think I also recall seeing one person that said only MS should be putting things into the GAC.  What the actual best practice is I'm not clear on, but it is a decision which should not be made lightly.

RockfordLhotka replied on Tuesday, September 12, 2006

The GAC complicates/prevents the use of no-touch and ClickOnce deployment schemes. Personally I avoid it as much as possible...

But to take this in a slightly different direction - the BinaryFormatter, which is actually doing the serialization that is version-sensitive, has some switches (especially in .NET 2.0) to allow you to communicate across versions of an assembly. To use this, you'd need to create a custom data portal channel so you could tell the BinaryFormatter to be more tolerant, and you'd need to use a new attribute (Optional I think?) on your fields as you add them to your class, and you'd need to make your object code tolerate those fields being not set... But it can be done.

Also, looking forward to WCF and the DataContract concept, you get the same thing. The ability to have different versions on each end of the wire - as long as you take the time and effort to write your code to tolerate missing field values, etc.