Soap Serializer does not support serializing Generic Types.

Soap Serializer does not support serializing Generic Types.

• _Rico_

  I don't this that is a good idea. It is a matter of consistency between the binary formmater and the SOAP formmater.
  

• BostonResident

  Xinzhang, can you include the code for both sides of the wire Looking at what you posted, it's not obvious to me what's going wrong.

  Cheers,

  JJustice [MSFT]

  
  

• Joe9999

  The Binary formatter can handle callbacks and events. Check out the Remoting FAQ over here for pointers.
  
  

• Michael Tumy

  I think the defficiencies of the XmlSerializer and sometimes the SoapFormatter are serious issues that need to be addressed in future .NET versions, or in WinFX. I havn't used Indigo, so I am not sure what kind of advancements have been made there. But its definitely something that needs to be addressed.

  I am currently working on a project where we had to ditch a months worth of work on a web services layer, and move the business logic onto the same server as our web server. There were too many issues serializing things. We now have had to slate time to design and develop our own distribution mechanism, using .NET Remoting and the BinaryFormatter, which will take another month or so to develop. All in all, the defficiencies of the XmlSerializer and .NET's native Web Service serialization capabilities have cost us several months of development time, and forced a reduction in the initial delivery of an application.

  While I do not think that Java is any better (on the contrary, it seems worse in many areas regarding serialization and web services), and we will not be changing off the .NET platform, serialization and web service capabilities in .NET are very dissapointing.

  
  

• AndrewBaylon

  I Agree: I use XmlSerializer to build documentation or to share information from different application. But I use SOAP or Binary serialization to Save and Reload the whole application object graph.

  Mi application evolves in time, so the internal structure changes and i need to reload also the old save version.

  For very little changes i can handle it in the code, but for big changes it can be impossible.

  So, until some week ago, I usually write code that load the xml of the soap-serialized apllication an conver it in the new structure.

  But now I've used some generics ... and I can't serialize it in soap format. And I've not found any instrument to manipulate the output of the binary serializer.

  I've also try to use a serialization surrogate, but it dos't work in .NET 2.0 ( see my other post:http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=194553&SiteID=1).

   and now I'm scraping my heads thinking about a good solution ...

   

  
  

• spurandare

  I have to agree with the others that XmlSerializer is a poor relation - it will not serialize fields of types without a default constructor - in particular the one that is causing me frustration is the System.Uri class. With a class that has a System.Uri field and a generic type field, neither the SoapFormatter nor the XmlSerializer will work - the only solution seems to be to use the BinaryFormatter.

  
  

• Sebastian Chiariello

  Thanks for your reply, I followed the link but no vail.
  
  My probelm is in the server to client evnt call back, I am still getting a "Soap Serializer error."
  This should not happen, because if you look att the code I provided above, I have already
  set it to binaryformat in the client code...so how come a soap serializer error pop up
  
  
  
  
  
  
  
  

• Alistair Leslie-Hughes

  Yeah, Let me post more codes about the configuration.
  What I am doing here is, I have a remoting server start, also to have the capability for a client to event call back to server, we defined a delegate and an event wrapper as the book "Advanced remoting said".
  
  Here is the definition:
  
  public interface IFactory
  {
  IWorker getNewWorker();
  }
  
  public delegate void PipelineDelegate(RemoteData rdo);
  
  public class CallbackPipeline: MarshalByRefObject
  {
  public delegate void RealLocal(RemoteData commitData);
  
  public RealLocal RealocalCall;
  
  public void CallForRemote(RemoteData commitData)
  {
  realocalCall(commitData);
  }
  
  public override object InitializeLifetimeService()
  {
  return null;
  }
  }
  
  That is basically the interface definition for client and server
  
  

• David Jarmoluk

  
  This is fine. I can live with use BinaryServerFormatterSinkProvider only.
  However, in our scenario, we are using event call back from server to client.
  So after I changed from SoapServerFormatterSinkProvider to BinaryServerFormatter
  in my client data connection file, with the following codes like these
  
  BinaryServerFormatterSinkProvider serverProv = new BinaryServerFormatterSinkProvider();
  BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider();
  
  //SoapServerFormatterSinkProvider serverProv = new SoapServerFormatterSinkProvider();
  //SoapClientFormatterSinkProvider clientProv = new SoapClientFormatterSinkProvider();
  
  serverProv.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
  
  //SoapClientFormatterSinkProvider clientProv = new SoapClientFormatterSinkProvider();
  
  IDictionary props = new Hashtable();
  props["port"] = 0;
  props["TypeFilterLevel"] = "Full";
  
  HttpChannel chan = new HttpChannel(props, clientProv, serverProv);
  ChannelServices.RegisterChannel( chan );
  
  It is working now for the client to server connection.
  
  
  however, because we do have events/delegation call back from server to client,
  so when the delegation fired, I am still getting the same error as
  "Soap Serializer does not support serializing Generic Types"
  
  
  So it looks like in the event call back, it is default using the soap serializer, is there anyway to set this to BinaryFormatter thanks.
  
  
  
  
  

• Drew Noakes

  I have to agree with Joseph on this. The XmlSerializer has some SERIOUS defficiencies that make it a very poor choice for serializing things. Aside from its inability to serialize private members, the XmlSerializer has issues serializing collections, and can't serialize anything that implements IDictionary at all. Class structures that contain circular references are also non-serializable, or their serialization is very limited.

  .NET is in dire need of a better serializer, and the SoapFormatter does pretty well, except for this lack of support for Generics. :(

  
  

• getter

  Actually XmlSerializer IS NOT an excellent option. It basically cannot serialize private members (public properties are pretty limiting), which is an important part of the state of an object (obviously). I find this rather shocking that this made it into the final release of the product.  Indigo/WCF is a long ways off.
  

• chrisbarber1

  This is the result of XML and WebServices being touted as a cure all for every data transmission woe we have.

  XML/SOAP has serious limitations among the most obvious being its verbosity. SOAP is PERFECT for extranet integration where you have no control over your partners' environments. It does not belong within an internal network ESPECIALLY when the communication is between two .Net applications.

  If you have two internal .Net applications that want to communicate, use .Net remoting with the binary formatter. It doesn't take much effort to switch applications that use the soap formatter over, and your network will appreciate the lighter load.

  There are even ways to get Java and .Net applications to communicate without SOAP. But that's a post for another day.

  
  
  

• RajanSelliah

  That is correct. We have decided not to invest in any significant new feature work for the SoapFormatter in Whidbey.
  
   -- Eugene Osovetsky
  
  

• Wesley P

  We are aware of that, but the SoapFormatter is and will continue to become less important as time passes.
  
  If you need an Xml projection of a CLR type, the XmlSerializer is an excellent option until Indigo ships.

  
  
• Soap Serializer does not support serializing Generic Types.