From the reading I've done I'm under the impression the DataContractSerializer handles versionong issues by, if members in the request are not there it will set the default value, and if addional members are in the request but not in the definition the serializer will simply ignores these fields and not process them.
Firstly, is this assumption correct?
Secondly, could you use this DataContractSerializer instead of the XMLSerializer so you can add this versioning ability to old asmx web services? Basically, if you add new members to your web service schema request you won't need to send to every client? When you receive the request from the client you can Deserialize using the DataContractSerializer into your object.
Hope this makes sense
You can use the DataContractSerializer outside of WCF to manually deserialize and serialize object graphs. However, you cannot tell ASMX to use the serializer. You are much better of just replacing your ASMX services with WCF services.
I have used the DataContract Serializer to import xml files, it works fine.
Related
I'm using Autofac with WCF integration in a project. I'm trying to figure out a way to lazy initialize data contract proxy collection properties to avoid transferring entire object graphs across the wire.
My current plan is to inject the WCF service in each deserialized data contract so they call the service, get the collection property data and initializes it.
My question is: Is there a way to tell Autofac to inject services in each data contract proxy deserialized at the client? Like some tweaking at the DataContractSerializer or something.
(No service locator, please...)
Thanks!
Unfortunately there is nothing like this available "out of the box" with Autofac. There is something similar in Autofac's MVC integration, but that's because MVC has a more specific integration point for that sort of thing (IActionInvoker).
You might be able to write a custom client-side behavior that intercepts certain known types (like collections) on the client and swaps in a lazy-initialized collection. There's a similar question here asking about how to swap the DataContractSerializer out at runtime. You could use a mechanism like that.
I have a Product Datacontract with a couple of Datamembers that are part of a WCF Service. I also serialise and store this Product Datacontract in my app using the DataContractSerializer.
Now, I want to remove some of the Datamembers of the Product Datacontract when the Service metadata (WSDL) gets generated. However, I want all Datamembers from the Product Datacontract to be available when I serialise the object within my app.
What I wanna do, actually, is this: grab hold of the WSDL generation process and remove the required Datamembers from being injected into the generated WSDL.
Thanks
Mofolo
Hacking WSDL to not contain the information will not help you. Your service will still use full serialization of your types when passing them to your client and when deserializing them from your clients. Instead of hacking WSDL and WCF use DTOs for WCF service = new set of types which will contain only properties you really want to exchange with clients. Convert your master object to DTOs and vice-versa (you can either create your own custom convertors or use some framework like AutoMapper). This is the best practice.
WCF REST service works great in a way that it will reply/accept JSON or XML depending on header.
I want to tweak built-in JSON serializer a little so it encodes/decodes Byte[] little different. More specifically, I want to use Base64 for that.
Is that any pointers/samples where I can set custom type serializer that will affect whole service?
The post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/05/03/wcf-extensibility-message-formatters.aspx shows how to replace the default JSON serializer (DataContractJsonSerializer) with a custom one (in this case, JSON.NET).
I just succeeded swapping out the default DataContractJsonSerializer with JSON.NET serializer in my WCF REST services 4.0 using NETFx Json.NET MediaTypeFormatter . Also see JSON.NET Serializer for WCF REST Services for the solution to a problem I ran into to get this working.
By default WCF use DataContractSerialization so if we can change it then my question is how to change it and when should we need which serialization on wcf ?
You can use the XmlSerializerFormatAttribute attribute on your service contract to force WCF to use the XmlSerializer.
WCF has a nice feature that a method can return Message or a Stream (see Returning raw json (string) in wcf and How to set Json.Net as the default serializer for WCF REST service as examples). The corresponding code which you need to write can be more easy as if you will use more advance techniques Extending Encoders and Serializers. So it is very easy to implement Streaming Message Transfer for example or just returning JPG or Excel file as a result of some WCF method.
The default choice of DataContractSerializer is good for most purpose. You can also use the DataContractJsonSerializer specially for REST type services and if the client expects Json content type. The other option is XmlSerializer for interoperability purpose if you need more control over the generated XML. DataContractSerializer is more efficient than XmlSerializer.
In 3rd party options you can use protobuf-net from Google which is more efficient than DataContract Serializer.
I want to pass list of entitiy objects from Client to WCF Service,
but my WCF Service has no knowledge of the structure of these entity objects.
One way could be to pass them in an XML file.
What could be the other possible ways to pass such objects to WCF service?
Please guide.
Thank you!
Basically, you need to make your WCF service aware of the structure.
Remember: calling a WCF service is passing a message (WCF is serialising an object, stuffing it into an envelope, and sending it away; this is not a remote procedure call or some object remoting!) and you need to make this message so that the caller and the callee can serialize and deserialize it!
Create DataContracts for your object classes being sent back and forth - that's the easiest way.
You can also work with untyped messages in WCF - but it's a lot more manual work, and I'd strongly recommend investigating the DataContract route first!
See a blog post and the MSDN docs on how to deal with untyped messages in WCF.
Marc
I would recommend against this since WCF is contract based. I would map the entities onto DataContracts in the service and work with them from there. Let me know if I'm missing something..