We use strongly named assemblies and have an effective and rigorous versioning process.
As you know, both the Client and the Server (read Data Portal Host) must have the same version available when serializing/deserializing CSLA mobile objects.
If you don't (for example the server has a newer version than the client) then you typically get a FileNotFoundException and a message along the lines of:
"Could not load file or assembly 'XXXX, Version=1.2.3.4, Culture=neutral, PublicKeyToken=XXXl' or one of its dependencies"
For us, we normally manage backwards compatibility with AssemblyFileVersion, but with Silverlight clients this does not help, and Out-Of-Browser (OOB) applications do not detect that there is a newer version available for upgrade, based solely on AssemblyFileVersion.
So, we need to change the AssemblyVersion, but that would break backwards compatibility. My question is therefore how can I have the CslaBinaryWriter / CslaBinaryReader / MobileFormatter allow serialization/deserialization when a part of the AssemblyVersion number is be different (say the last 2 numbers of the 4 part version number). It would be great if I can have it fail (as it does now) when the Major / Minor numbers differ?
Many thanks,
Jaans
--------------------------------------------------------------------------------------------
For those wanting more detail, below is a more long-winded-background blurb.
We maintain our backwards-compatible builds by incrementing versioning only for the AssemblyFileVersion and retain the same AssemblyVersion for versions of assemblies that are compatible. The CSLA Mobile Object serialization doesn't break because the AssemblyVersion of the client and the server still match.
When changes are made that breaks backwards compatibility (due to either API change or more substantial features) we would obviously increment our AssemblyVersion, and usually the Major/Minor parts. This is pretty standard stuff in the .NET side of things and works very well.
The key takeaway from this is that in .NET the assembly loading is smart enough to know to reload an assembly if it's AssemblyFileVersion is different, despite the AssemblyVersion being the same. This is great as it allows us to deploy critical patches and hotfixes to the offending assemblies only to production environments.
However, on the Silverlight side things are not so "easy", mostly because the AssemblyFileVersioning doesn't translate to the browser and specifically not to an Out-Of-Browser (OOB) Silverlight application.
The simple solution would be to change the AssemblyVersion, specifically only the 3rd or 4th parts of the 4 part version number (build and revision depending on your flavour of juice). e.g. v2.2.0.0 gets a backwards compatible patch as v2.2.0.1.
In Silverlight, when the change to the AssemblyVersion is made, the new version is downloaded, and most importantly for us, the OOB application can detect that there is a new version available and update itself. The bad bit with it is that already installed but not-yet-upgraded OOB applications will break when they interact with the server due to the version number skew.
Apologies - I just discovered we had a problem with our version generation for Silverlight. Silverlight does in fact honour detecting a change to the AssemblyFileVersion as an update when the AssemblyVersion is kept the same.
So that resolves my issue above.
However, the concept still intrigues me - would you want to be able to control what is deemed compatible versions or not, when you potentially update only the server or only the client?
Copyright (c) Marimer LLC