title: BinaryFormatter - Is it possible to deserialize known class without the assembly?
body: <p>I am currently trying to interoperate with a program that sends data over the network after first formatting it with C#'s BinaryFormatter.  It's a dumb idea, and I hate it, but I have to interoperate with it.</p>
  
  <p>I know what the type looks like, I know it's exact layout.  But I can't add a reference to that specific assembly in my program for various reasons.</p>
  
  <p>Given how tightly coupled BinaryFormatter is to the specific type/version, I can't seem to find a way to get it to deserialize despite knowing the data structure.</p>
  
  <p>I'm currently look at either creating a fake assembly with all the right attributes and attempting to link that in (seems really messy), or manually attempting to go through the binary stream and extract the values I'm looking for (I'm looking at the MS documentation on this, and it's clear as mud as to the layout).</p>
  
  <p>Any other great ideas, or has anyone had successes with this in the past?  It seems like I know all the information that I need, and BinaryFormatter is just being notoriously fragile about it.</p>
  
  <p>edit:</p>
  
  <p>To answer the question below (which is a good point, btw) there are a couple of reasons.  </p>
  
  <ol>
  <li><p>Project cleanliness.  Adding a 5MB reference to an .exe that's external for one feature is  a bit off.</p></li>
  <li><p>The pieces of equipment I'm interoperating with have various versions deployed around the world.  The internal data structure for the item I care about is the same across all of them, but the versions of the assembly are different, causing breakage with BinaryFormatter.  I could convert the binary stream to a string, search for the version number then load the proper version, but now I have a dozen .exe's laying around waiting for me to load the right one.  Then that scheme is not very future proof (well, this whole scheme isn't really future proof, but I'd at least like to abstract away some of the fragility of BinaryFormatter to make my job easier).  Just writing this response has got me thinking about using emit or similar to create a custom assembly on the fly.....but man, there has to be an easier way, right?  I'm literally looking for a couple of bools in a medium sized data structure.</p></li>
  <li><p>The object's variables are exposed through get/set properties that have some logic to them, and try to make function calls and update other objects that might not be present on my side (aka, a get gets me the value I need, but also triggers notifications that ripple through the linked dependency and I can get exceptions bubbling up to my application.  Talk about code smell!).  It turns into a dependency/implementation rabbit hole.</p></li>
  </ol>
  
  <p>edit2: The manufacturer is working with me to make their system better, but when we advertise "Works with X" we'd like it to just work with X, not require specific versions.  Particularly with some of our customer systems that are tightly version controlled, and just updating the offending application becomes a major effort.</p>