| Author |
Message
|
| kayoumt |
 Posted: Mon Oct 22, 2007 2:23 pm Post subject: C# Application can not bypass local queue manager |
 |
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
I'm developping MQ C++ and C# applications on desktop and laptop. On each of the two machines I did a full installation (server + client) of MQ V6. I want to be able on each of the two machines to connect my application on local MQ queue manager or to remote Queue manager.
In C++ this does not seem to be a problem. The way to connect to queue manager is determined by MQ libraries linked to the application. Two executables of the same application could do the business.
But, for C#, I tried anything and got nothing working. Either I got something telling me that there is a problem with MQM.DLL or MQIC32.DLL or got 2058, 2059 errors.
It seems the C# application cannot bypass the local queue manager !!!
I tried any ways of calling the queue manager constructor, any ways of setting variables MQSERVER, GMQ_MQ_LIB, NMQ_MQ_LIB, any ways of setting c# class Environment members ; I did not have it working.
Thanks in advance for any help. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Oct 22, 2007 7:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Read the manual (Using .NET). You need to use the MQEnvironment class or its equivalent.
I don't believe that the environment variable is relevant in C# but then the manual could prove me wrong...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kayoumt |
| Posted: Mon Oct 22, 2007 9:12 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
fjb_saper,
I readed that document at least 3 times. I readed lot of other documents. It did not help me.
I'm developing on MQ with C# and C++ since more than 1 year and half.
1) I have NO TROUBLE having application, MQ Client and MQ Server on the same machine.
2) I have NO TROUBLE when I have application and MQ Client (only) on a machine and MQServer on remote machine.
3) I have TROUBLE when I have full installation (Client+Server) on each of the two machines.
Could someone some give me a little bit helpful information ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 22, 2007 10:36 pm Post subject: Re: C# Application can not bypass local queue manager |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kayoumt wrote: |
It seems the C# application cannot bypass the local queue manager !!!
|
It certainly can as a general principle; .NET supports not only the "normal" client connections but also managed client connections which are specific to this technology.
Where I've done it (which is not extensively) I've set NMQ_MQ_LIB and the MQEnvironment.
I feel I should also point out that if one of your attempts threw a 2059 error, then it was attempting a client connection and one of the many, various and probably not code related problems that cause 2059 had got in your way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 3:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In this case, it's likely the 2059 was trying to connect to a local qmgr on the machine, that didn't exist... rather than trying to make a client connection to the other machine.
There's a page in the Using .NET manual that goes over the exact ways that a server, client, or managed client connection is chosen and then established.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Oct 23, 2007 9:41 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
I did tests again :
- whatever value (null included) I specify for MQEnvironment parameteres.
- Whatever value I specify for NMQ_MQ_LIB (POUTINE.DLL included)
- whatever MQQueueManager constructor I use
I get the error below :
Unable to load DLL 'mqic32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 9:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That means that it can't find the MQ Client library.
This is good news to the extent that it means that you've successfully told it to make a client connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Oct 23, 2007 11:41 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
I got it or got very close to a solution !
I completely changed the way I was giving properties to the queue manager. Instead of using MQEnvironment, I used the Hashtable properties (second parameter of Queue manger constructor). I tried all the 5 possible values of MQC.TRANSPORT_PROPERTY :
MQC.TRANSPORT_MQSERIES
MQC.TRANSPORT_MQSERIES_BINDINGS
MQC.TRANSPORT_MQSERIES_CLIENT
MQC.TRANSPORT_MQSERIES_XACLIENT
MQC.TRANSPORT_MQSERIES_MANAGED
It works only with MQC.TRANSPORT_MQSERIES_MANAGED even if I do not specify the environment variable NMQ_MQ_LIB. Probably this option makes the API check the hostname and automatically determines if it has to call MQIC32.DLL or MQM.DLL ?
However ; I saw in the "Using .NET" the text below, telling me that that solution is limited :
Managed client connectionsEnd of change
------------------------------------------------------------------------------------
Start of changeWhen WebSphere MQ classes for .NET are used as a client, it is similar to the WebSphere(R) MQ C client, but has the following differences:
* Start of change The following features are not available:
o Channel compression
o SSL support
o XA transactions
* Channel exits written for a non-managed client will not work. You must write new exits specifically for the managed client.
* Communication is supported only over TCP/IP.
----------------------------------------------------------------------------------------
Anyway, that solution will help me terminating the development and tests of my software. If those not provided funtionalities do not come, I will have two executables, exactly like I do for C++.
If someone find a better way to deal with that issue, please let me know. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 12:50 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No.
A managed connection does not use mqic32.dll. It uses a "100% pure .NET" client implementation - and this is at present more restricted than the regular client library.
Again, this points to either you don't have the MQ Client installed, or you don't have it on the path correctly for your app.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Oct 23, 2007 1:53 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
| What I need is one and only C# executable and one and only one C++ executable that could connect to a LOCAL or to a REMOTE queue manager without I do any change or re-compilation of the code. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 23, 2007 2:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kayoumt wrote: |
| What I need is one and only C# executable and one and only one C++ executable that could connect to a LOCAL or to a REMOTE queue manager without I do any change or re-compilation of the code. |
Which is a good definition of an application using a client connection. Such connections are often used to allow applications to be used with a variety of queue managers 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Oct 23, 2007 3:09 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
| According to the results of the couple of tests I did since I discovered the .NET managed connection. It allows that feature (CLIENT CONNECTION from "anywhere"). But, unfortunately, as far as I know, it is very restricted. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 4:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.
Let's be clear.
If you are able to successfully compile your .NET application on a machine that correctly has the MQ Client correctly installed and your app is using a non-managed client connection... then you will be able to run that .NET application on any machine that also has the MQ Client correctly installed on it. Without any concern of whether the queue manager your app is connecting to is on the same machine or a different machine.
If you want your app to just run "anywhere", regardless of whether that machine has the MQ Client installed on it or not, then you will need to use a managed client connection - and distribute an additional DLL with your code.
If your code is unable to successfully compile and run using a non-managed client connection - then your compilation machine DOES NOT HAVE A GOOD CLIENT INSTALL ON IT.
Or your compilation environment IS NOT SET UP CORRECTLY. I.E... mqic32.dll is not on the PATH or the build path, and the libraries/includes are not on the right paths.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kayoumt |
| Posted: Tue Oct 23, 2007 5:58 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
jefflowrery,
To be clear, let's go point by point.
-- COMPILATION --
First of all ; forget about compilation problems. I never had compilation problems. For .NET, I link only one dll (amqmdnet.dll) to my VS .NET project. It works, number One, be it with managed or unmanaged mode.
-- EXECUTING CODE COMPILED WITH UNMANAGED CLIENT (MQIC32.DLL) --
1) From a machine on which ONLY MQ CLIENT is installed (SERVER IS NOT INSTALLED) I can run my application and connect to remote queue manager. Be it by setting MQEnvironment or setting MQSERVER variable.
2) On a machine with FULL MQ INSTALLATION (Server + Client), my application can run by connecting to LOCAL QUEUE MANAGER.
3) On a machine with FULL MQ INSTALLATION (Server + Client), my application HAVE TROUBLE connecting to REMOTE QUEUE MANAGER. It seems, it cannot BYPASS the LOCAL QUEUE MANAGER.
-- EXECUTING CODE COMPILED WITH MANAGED CLIENT --
It works number One in the three cases (that's what I called "anywhere").
1) CLIENT ONLY INSTALLED + REMOTE QUEUE MAAGER
2) FULL INSTALLATION (LOCAL QUEUE MANAGER)
3) FULL INSTALLATION + REMOTE QUEUE MANAGER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 23, 2007 10:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kayoumt wrote: |
2) On a machine with FULL MQ INSTALLATION (Server + Client), my application can run by connecting to LOCAL QUEUE MANAGER.
3) On a machine with FULL MQ INSTALLATION (Server + Client), my application HAVE TROUBLE connecting to REMOTE QUEUE MANAGER. It seems, it cannot BYPASS the LOCAL QUEUE MANAGER.
|
Then this machine has an issue with the client installation and the MQI calls are being resolved by mqm.dll not mqic32.dll (or whatever they're called these days) irrespective of the settings within the code.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
