CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Disabling Version Tolerant Serialization

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 5 Replies | 1 Follower

    Top 150 Contributor
    65 Posts
    Matthew Copeland posted on Fri, Jul 12 2013 4:06 PM

    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?

     

    Answered (Verified) Verified Answer

    Top 150 Contributor
    65 Posts

    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? Smile

     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.  

     

    All Replies

    Top 10 Contributor
    9,475 Posts

    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.

    Rocky

    Top 10 Contributor
    2,279 Posts
    Suggested by JonnyBee

    Hi,

    A simple solution may be to set the version number into ClientContext and add a custom check in IAuthorizeDataPortal with the "current" version.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 150 Contributor
    65 Posts

    RockfordLhotka:

    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 :).

     

    Top 150 Contributor
    65 Posts

    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? Smile

     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.  

     

    Top 150 Contributor
    65 Posts

    JonnyBee:

    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.

    Page 1 of 1 (6 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems