0

I have the following code in a web method of a .NET 2.0 VB web service application:

<WebMethod()> _
Public Function UpdateCall(<System.Xml.Serialization.XmlElement("CallChangeRequest")> ByVal callChange As CallChangeMessage) As Boolean

Dim result As Boolean = False
Dim mq As System.Messaging.MessageQueue = Nothing
Dim msg As System.Messaging.Message = Nothing
Try
    mq = New System.Messaging.MessageQueue(System.Configuration.ConfigurationManager.AppSettings("queueName"))
    mq.Formatter = New System.Messaging.XmlMessageFormatter(New Type() {GetType(CallChangeMessage)})

    msg = New System.Messaging.Message(callChange)
    msg.Recoverable = Convert.ToBoolean(System.Configuration.ConfigurationManager.AppSettings("recoverableMessages"))

    mq.Send(msg)

    result = True
Catch ex As Exception
Finally
    If Not (msg Is Nothing) Then msg.Dispose()
    If Not (mq Is Nothing) Then mq.Dispose()
End Try

    Return result

End Function

This code correctly serializes my object and writes an XML message to the message queue on my old local development machine, which was running Windows XP Pro 32-bit. It also performs correctly on the production server. After upgrading to Windows 7 64-bit, this code will no longer write the XML message in the message queue. The call to msg.Send(msg) does not raise an exception, so my web method returns true to the caller. However, no message is written to the queue, so the code is just quietly failing.

The messages are marked as Recoverable, and the queue name is FormatName:DIRECT=OS:.\private$\inbounddata. I've opened up the permissions for basically everyone to do everything. If there were a permission problem, I would expect to get some sort of exception, so I don't think I have a permission problem. The web service is running in an application pool targeting the 2.0 framework with managed pipeline mode set to Classic.

Up to now, my recourse has been to deploy the code on my old development box, which I still have hanging around, but I cannot do that forever. Is there a problem with my code that is causing this to fail? Does anyone know of any issues with writing to MSMQ on Windows 7 64-bit from a 32-bit .NET 2.0 framework app?

Thanks for any help!

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Rich Miller
  • 810
  • 1
  • 9
  • 20
  • Is it possible the problem is an IPv6 issue instead of an OS issue? – Mutt Jun 08 '11 at 14:34
  • @Mutt, how would I diagnose that? It appears my machine has both IPv4 and IPv6. If I disable IPv6 will I cause myself undue grief? I believe our network is using all IPv4 addresses. – Rich Miller Jun 08 '11 at 15:00
  • I checked the event log, and MSMQ is not raising any errors about listening on either IPv4 or IPv6 addresses. Also, I am not using an IP address in the queue FormatName, so I don't think that is my issue. – Rich Miller Jun 08 '11 at 15:09

1 Answers1

0

Don't know what happened, but I deleted the existing queue, created a new queue, and now all is well. Thanks for the suggestions.

Rich Miller
  • 810
  • 1
  • 9
  • 20
  • That's weird. What you could do - if you have a backup - is to compare the config files in the \msmq\storage\lqs folder for the broken and working versions of the queue to see if there is a configuration difference not obvious in the UI. – John Breakwell Jun 09 '11 at 12:08