JSON deserializer doesn’t recognise __type if formatted

I’ve noticed that the .NET DataContractJsonSerializer doesn’t recognise the __type if you format the JSON and it’s not the first __type in the document.

To workaround this but still have semi-formatted JSON, ensure the “__type” immediately follows the opening curly brace.

Advertisements

Azure cmdlets timeout workaround/hack

I know that fixing a timeout issue by increasing the timeout is probably the worst idea but hey, needs must…. ­čÖé

When you install the Azure cmdlets, it compiles the source code. Therefore allows you to amend the source code before this happens:

C:\WASMCmdlets\code\Microsoft.Samples.WindowsAzure.ServiceManagement\ResourceModel\ServiceManagementHelper.cs

Change the CreateServiceManagementChannel methods to include these lines:

factory.Endpoint.Binding.SendTimeout = TimeSpan.FromMinutes(2);
factory.Endpoint.Binding.ReceiveTimeout = TimeSpan.FromMinutes(2);

…before the factory.CreateChannel();

Then run the startHere.cmd again otherwise you’ll get a strong name exception.

However I still get timeouts for GetDeployment, this is no longer a client side WCF timeout issue as I tried using HttpWebRequest against the ServiceManagement REST API setting both Timeout and ReadWriteTimeout. It appears this is a server side timeout of around 2 minutes resulting in

“The underlying connection was closed: The connection was closed unexpectedly.”

I’ve not found a way around this yet other than to try another approach that doesn’t use/need this method.

UPDATE 8/4/2011: About 5pm last night GMT this issue went away and the GetDeployment call that was taking over two minutes now runs in 8 seconds – we didn’t change anything so….┬á­čśÉ

FIX: WCF Streamed webservice message exceeding 65536 bytes despite “correct” maxReceivedMessageSize setting.

“The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.”

The config file already had a bindingConfiguration specified for the endpoint that had a maxReceivedMessageSize=”67108864″ attribute. But it still wasn’t making a difference.

Fix: In the end it turned out that it was the <service name=”MyService”> element that was incorrect, it should have been fully qualified to the class name of the service, i.e. – <service name=”MyNamespace.MyService”> without this it was basically ignoring this configuration and falling back to default of 65536 max message size.

DataContractSerializer threw System.NullReferenceException: Object reference not set to an instance of an object..

I got the following exception during serialization of an object:
 System.NullReferenceException: Object reference not set to an instance of an object..

System.Runtime.Serialization.XmlObjectSerializerWriteContext.OnHandleIsReference(XmlWriterDelegator xmlWriter, DataContract contract, Object obj)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithXsiType(XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle objectTypeHandle, Type objectType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle, Type declaredType)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerializeReference(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
WriteEventEditionToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , ClassDataContract )
System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph)
System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph)
System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph)
System.Runtime.Serialization.XmlObjectSerializer.WriteObject(XmlDictionaryWriter writer, Object graph)
System.Runtime.Serialization.XmlObjectSerializer.WriteObject(Stream stream, Object graph)
ReedExpo.Nova.UnitTesting.Events.EventHandlerTests.Test_TestSerializeEventEdition() in D:ProjectsNOVA PlatformWorkingReedExpo.NovaReedExpo.Nova.UnitTestingEventsEventHandlerTests.cs: line 85 

Turns out there were two reasons I encountered this:

  1. I hadn’t marked the type as a [DataContract] which meant public properties not marked as [DataMember] were still being serialized (I believe this happens post 3.5 SP1)
  2. More significantly, the return type of the property was a generic IList<MyType> (if I changed this to be a concrete class then the error goes away).