CODEWITHSUNDEEP
.netmsmq.net-4.5
Talonj
Talonj

Reputation: 2288

MSMQ doesn't work cross-server with .net framework 4.5

After installing VS2012, and attempting to use an ancient app that hasn't been modified meaningfully in years, MSMQ messages were being lost.

Research proved that they were being processed on the target server, but not returned correctly because the Response queue was incorrect. It was using a PRIVATE: format instead of the DIRECT:OS: format that was passed in to the constructor.

Specifically, this is executed:

Dim lobj_Queue As New MessageQueue("FormatName:DIRECT=OS:" & astrServer & "\" & astrQueue)

where astrServer is the name of my local machine and astrQueue is the name of the response queue that I want the response placed into.

The resulting format name of the queue is "PRIVATE=d69f93e2-18f1-42eb-a468-84ca521efb5b\00000298" which is not translatable for cross-forest activity.

Running the same app built for .net framework 3.5 worked properly.

It seems that .net 4.5 attempts to automatically resolve queue formats. At one point, according to http://connect.microsoft.com/VisualStudio/feedback/details/762194/accessing-messagequeue-formatname-throws-an-exception-on-queues-returned-by-getprivatequeuesbymachine-remotemachine-on-a-workgroup-computer#details this behavior caused an exception.

Debugging into the source of the MessageQueue.FormatName property shows that currently, the exception that is thrown is handled, and it falls back to the previous method of parsing the queue path. This generates a valid queue path the first time for the target server, so the message gets to the server and is processed, however when generating the response queue on the local machine, the call succeeds and generates a format name that is incomprehensible to the target server, so the server's response is never received, and remains in outgoing queues eternally.

Is there any way to continue to make this work? As far as I can see, there is no way to use a private response queue because any name you generate locally will be only be understandable on the same forest.

I am hoping there is something I am missing, that there is an obvious solution to do this given the complete lack of answers for this specific scenario.

Upvotes: 4

Views: 1174

Answers (1)

Talonj
Talonj

Reputation: 2288

After dealing with inefficient workarounds for awhile, one of our coworkers found the fix to the issue:

On the client computer, you need to uninstall the Directory Services Integration feature, which is under Message Queuing and Message Queuing Services.

Then requests are able to be routed back to the sender properly. I'm not sure if this feature was added automatically by .NET 4.5 or simply modified by it, but disabling it instantly fixed the problem (The running web application didn't even restart - the next request just worked)

Upvotes: 3

Related Questions