I was surprised to find that I could compile a new version of a business assembly 1.0.0.1 (the only change being the assembly version), host it in WCFDataPortal and run a client compiled against the previous version 1.0.0.0 with no problems.
I say this because I thought that the default value of BinaryFormatter.AssemblyFormat was FormatterAssemblyStyle.Full which should cause an exception when attempting to deserialize the 1.0.0.0 type into the 1.0.0.1 type.
After some research, I believe this behavior is because my business assembly is not strongly named
Is there an easy way to force CSLA to throw a serialization exception in this case without using a strong name?
For the most part if you are using wcf you are using netdatacontractserializer. It is a near clone of binaryformatter in terms of behavior, but there are differences.
For the most part if you are using wcf you are using netdatacontractserializer. It is a near clone of binaryformatter in terms of behavior, but there are differences.
My OP applies equally to the NetDataContractSerializer. By default its AssemblyFormat property is set to FormatterAssemblyStyle.Full. This should cause a serialization/deserialization exception if there is a version mismatch between type instances.
I looked through the 3.8.3 source code and it does not appear that this property is being changed to FormatterAssemblyStyle.Simple which would allow types with different versions to be serialized/deserialized interchangeably. Am I missing something?
Again, I believe the behavior being observed is because the business assembly is not strongly named.
"By default, the formatters comply with the version-binding and assembly-resolving policies of the common language runtime (CLR). If the serialized type's assembly does not have a strong name, the formatters try to load a private assembly and completely ignore any version incompatibility between the version captured during serialization and the version of the assembly found."
http://msdn.microsoft.com/en-us/magazine/cc163902.aspx (This article is aboput .Net 2.0 so things may have changed).
I was hoping that someone had experienced this and had a configuration solution without the processing overhead of Jonny's solution.
It seems ridiculous that I cannot easily configure a formatter to throw a serialization exception in this situation. Requiring that old clients be compatible with newer type versions is easily dangerous, and poor design in my opinion. To be clear this is a jab at .Net, not CSLA :).
Hi,
A simple solution may be to set the version number into ClientContext and add a custom check in IAuthorizeDataPortal with the "current" version.
Hi,
A simple solution may be to set the version number into ClientContext and add a custom check in IAuthorizeDataPortal with the "current" version.
Thanks Jonny. This would work but it does have two issues.
It adds overhead processing for every call, whereas the CLR throwing an exception only adds overhead in the instance someone makes a call with a client compiled against the older version.
As I stated in my answer, it is not truly secure as someone can manipulate the client's assembly version.
Strongly naming your business assembly appears to be the only answer. I have had little experience with strong names and have had colleagues talk of 'nightmares'. After a little research I am no longer afraid to do this. If Rocky isn't afraid to strongly name CSLA, why should I be afraid? 
If you cannot strongly name your business assembly, you are SOL. I received no answer on MSDN forums or stack overflow on how to do it without a strong name. After further thought this made sense. I realized one cannot securely enforce zero tolerance (de)serialization without a strong name due to the fact the version can easily manipulated within the client assembly.
Copyright (c) Marimer LLC