I have a BizTalk 2006 app which has a sendport using MSMQ.
I have also a WCF winforms hosting app with several WCF services (in the development environment, in production I use a windows service as hosting).
One of the WCF services that I created has a MSMQIntegrationBinding (due to the fact that BizTalk is not a WCF service, so NetMSMQBinding is not possible).
I see that the message is correctly placed on the remote queue because I activated the journal option and I see the message in the journal queue, but the queue is empty and the WCF service is not picking up the message.
Can anybody give me a clue where to look at to solve this problem ?
(edit 1): I have done some more research on this topic:
- When communicating with BizTalk 2006 R2 with MSMQ you have to use MSMQIntegrationBinding because NetMSMQBinding is only for WCF-to-WCF
- So I am stucked to MSMQIntegrationBinding
- the MSMQIntegration binding doesn't use DataContract serializer. Instead, it serializes the data based on the MsmqMessageSerializationFormat property. The default value for it is MsmqMessageSerializationFormat.Xml which means that XmlSerializer will be used. The rationale behind this is that the msmq integration transport is designed specifically to interop with native MSMQ / System.Messaging applications
- Because the MSMQIntegration binding uses the plain old XmlSerializer, I do not have the easy ability to use the svcutil.exe to generate my data classes. So I have to create my datacontract classes by hand....pfffffffffff
(reference: http://social.msdn.microsoft.com/Forums/en/wcf/thread/2d48fe90-5c2a-4156-8a3f-2e21d5638fa1 and http://www.danrigsby.com/blog/index.php/2008/03/07/xmlserializer-vs-datacontractserializer-serialization-in-wcf/)
(edit 2):
I checked the diagnostic trace data from the WCF service and the message was dropped due to a deserializing exception. The only solution now is to create the datacontract class by hand...
(edit 3): by using the xsd.exe tool instead of the svcutil.exe I created the datacontract class, so no handcrafted work here ;-) So the conclusion is to use xsd.exe for data contract classes that are used as parameter in the WCF service method. This is because MSMQIntegrationBinding forces you to make all datacontract types as being serializable with the XMLSerializer instead of the default DataContractSerializer.
You may want to try enabling WCF Tracing.
It may help you understanding what is happening, and what is not happening.
The following is an
.config
example to enable tracing. Make sure the.config
file is located in the same folder of your WCF service host.Microsoft provides a Service Trace Viewer Tool to read .svclog files.
Make sure the path in
initializeData
is writable by your service.