DataContractSerializer: Working with class inheritence and circular references

DataContractSerializer is the default serializer used by WCF Services. Typically, we transmit data objects generated via Entity Framework or LINQ To SQL and do not get any serialization issues as the generated classes are ready to handle various serialization scenarios. Some days back, I needed to transmit my own business objects on the wire; encountered a few issues and learned how to handle them. This post will highlight two such issues that may happen when we transmit our own classes via WCF service.

  1. Dealing with inheritance hierarchies
  2. Dealing with circular references

Read the rest of this entry »

Advertisements

WCF Service: Getting to the cause of error

If you are using WCF service as your mode of communication between client-server applications (and why shouldn’t you, this has been a great source of communication available since .NET 3.5), then there are chances that something wrong happened and you get a generic Communication Exception at your client. This post will highlight how to find the cause of such error.
Read the rest of this entry »

Silverlight: Update service reference for a WCF service generating empty class

My Visual Studio sometimes goes angry. I had a Silverlight 2 – WCF – LINQToSQL application that I recently converted to Silverlight 3. I noticed that sometimes the Update Service Reference does not function properly and instead blanks out the generated reference.cs. It broke once again today and I decided to blog it. Here are the contents of Error window when such abnormal activity happens:

Custom tool error: Failed to generate code for the service reference '..'.  Please check other error and warning messages for details.

The warning tab may have many warnings, some of which are:

Custom tool warning: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Custom tool warning: The type 'System.Collections.ObjectModel.ObservableCollection`1' could not be found.  Ensure that the assembly containing the type is referenced.  If the assembly is part of the current development project, ensure that the project has been built.

Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Exception has been thrown by the target of an invocation.
XPath to Error Source: //wsdl:definitions[@targetNamespace='']/wsdl:portType[@name=..]

Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='..']/wsdl:binding[@name='..']

Custom tool warning: No endpoints compatible with Silverlight 3 were found. The generated client class will not be usable unless endpoint information is provided via the constructor.

Ok. Looks like something is wrong with the Observable Collection reference. This was further confirmed when I brought up the service configuration window (by right clicking the WCF service and selecting Configure Service Reference), and noticed that the ObservableCollection collection type has been replaced by { Custom } :

service-reference-incorrect

For comparison, here’s the normal screenshot for this window:

service-reference-correct

To get rid of this and regenerate service proxy properly, I had to remove the Reuse types in all referenced assemblies (or at least System assembly).

So, if such behavior ever happen to you, try to update the service reference after unchecking the reuse types checkbox. Once done, you can recheck the option and update your service reference again.

Deploying a Silverlight Application and WCF Service to IIS

While deploying a Silverlight application on IIS today, I learned several new things. Let me express my observations; This post is going to describe the security settings for WCF service in web.config. To start, I assume that you are using either Windows or Forms authentication and denying all the anonymous users as described in a previous post.

First, make sure to remove the mexHttpBinding endpoint as this requires you to enable anonymous access to the website in IIS. The mexHttpBinding endpoint will look something like:

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

 
BasicHttpBinding

Typically, in your application, you will also be using some custom basicHttpBinding configuration for your WCF service endpoint, like this one:

<endpoint address="" binding="basicHttpBinding"
 contract="SilverlightApplication.Web.WCFService"
 bindingConfiguration="myCustomBasicHttpBinding" />

Using a custom binding allows you to configure buffers and quotas as described in this post. The definition of this custom binding will look something like:

<bindings>
 <basicHttpBinding>
  <binding name="myCustomBasicHttpBinding">
  <security mode="TransportCredentialOnly">
   <transport clientCredentialType="None"/>
  </security>
  </binding>
 </basicHttpBinding>
</bindings>

The <transport clientCredentialType=”None”/> is the main point of interest here. If you are using Forms Authentication, you need to allow anonymous access through IIS and set the clientCredentialType to None. If you want to run your application under Windows Authentication, you should use clientCredentialType="xxxx" where xxxx is the corresponding IIS authentication type. So, to work with Integrated Windows/Basic/Digest/NTLM Authentication, the xxxx should be replaced by Windows/Basic/Digest/Ntlm respectively.

 

Update: Custom Binary Binding

Similar change is required for custom binary binding:

<customBinding>
 <binding name="myCustomBinaryBinding">
  <binaryMessageEncoding >
   <readerQuotas ... />
  </binaryMessageEncoding>
  <httpTransport authenticationScheme="Anonymous" ... />
 </binding>
</customBinding>

Again, the point of interest is the authenticationScheme attribute in the httpTransport element that needs to match the IIS authentication setting (e.g. Anonymous for Forms Authentication, Ntlm/Basic/Digest for Windows Authentication).

This way, the WCF service should work without any problems.

Silverlight-enabled WCF Service template

Before Beta 2 of silverlight 2, we needed some tweaks with the standard WCF service template to use it in our silverlight application. But luckily, the new Silverlight-enabled WCF Service template does the job lot easier for us. Now we just need to define our methods(marked with OperationContract atribute) in the service.svc.cs file and we are ready to consume it. No need to change the binding configuration to basicHttpBinding, no need to add ASP.NET compatibility support in special cases, no need to define method signatures in a separate contract file. Just use the new template and use the service in your silverlight application without any worries.