| Author |
Message
|
| dtgruber |
 Posted: Wed Sep 26, 2012 4:44 am Post subject: Deploying application without MQSeries Client installation |
 |
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
Hi all,
I have been trying for quite some time now to deploy my little MQ Series sample application on a machine without the MQSeries Client installed.
I am now stuck with the following exception:
StackTrace: System.TypeInitializationException: The type initializer for 'IBM.WMQ.MQQueueManager' threw an exception. ---> System.TypeInitializationException: The type initializer for 'IBM.WMQ.CommonServices' threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at IBM.WMQ.CommonServices..cctor()
when the MQManager is instantiated.
Is there a way to deploy my application by just referencing the necessary libraries? Or do I have to install the MQSeries Client on every machine I want to run my sample app on?
Thanks in advance
Dominik |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Sep 26, 2012 4:48 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
It is good practice (best practice in my view) to always install the WMQ Client. Deploying WMQ files with your application is a step on the road to multiple versions of WMQ files, in different directories, on the same machine, and no way to properly manage them.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dtgruber |
| Posted: Wed Sep 26, 2012 5:15 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
Thanks for your quick reply!
how could I still deploy the application without having to install the client?
Unfortunately I could not figure out what else I would need to get the application running. I was deploying the amqmdnet.dll and amqmdxcs.dll with my application which seem to have dependencies.
I have tried to deploy other WMQ based assemblies I had found in the GAC with my app but with no effect.
Are there registry entries that need to be made? Or is there a need for a certain service to be active?
I'd prefer this method over installing the WMQ client because the sample application is running in an automated test environment for integration testing where installing the WMQ client is not the easier option at the moment.
Thanks in advance
Dominik |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Sep 26, 2012 5:55 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
You can install the MQ client "silently" easily enough.
It's really not advisable to try any other method of avoiding this simple (and free) pre-requisite.
I would suggest using MQ client version v7.0.1.9 unless you have a preference for another version for some reason (I assume your queue manager is v7.0.1.x). |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 26, 2012 8:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dtgruber wrote: |
| how could I still deploy the application without having to install the client? |
You could use a managed client connection from .NET, which doesn't require it.
| dtgruber wrote: |
Unfortunately I could not figure out what else I would need to get the application running. I was deploying the amqmdnet.dll and amqmdxcs.dll with my application which seem to have dependencies.
I have tried to deploy other WMQ based assemblies I had found in the GAC with my app but with no effect. |
As my associates correctly point out, it's never a good idea to try and install bits of the client. It seldom works and if it does, you can't rely on it.
| dtgruber wrote: |
| Are there registry entries that need to be made? |
Yes. All the changes the installer makes when it installs the client.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dtgruber |
| Posted: Wed Sep 26, 2012 8:04 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
EDIT: Thanks Vitor! I will have a look into Managed Client Connections asap. I ll keep you updated.
Thanks!
I appreciate your efforts pushing me towards the WMQ Client Installation solution.
Nevertheless installing the client "silently" will still produce overhead, also uninstalling the client which is needed to clean up after a test run. Considering the big amount of other tests running this is still not the preferred solution. 
I have found 4 additional assemblies that get loaded with the applications' process (note: with the WMQ Client installed): mqe.dll, mqecs.dll, mqic.dll, mqzsd.dll
I suppose those will take care of the MQ Environment etc. and will get loaded dynamically when needed. Furthermore I suppose this will happen via registry settings. I have found several keys in the registry pointing to those libraries.
I'd be very thankful if someone could push me into the right direction, my assumptions might also be completely wrong.
Has anyone ever tried to do this?
Thanks in advance
Dominik |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 26, 2012 8:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dtgruber wrote: |
| I'd be very thankful if someone could push me into the right direction, my assumptions might also be completely wrong. |
The right direction is to either install the client or use a managed connection.
| dtgruber wrote: |
| Has anyone ever tried to do this? |
Many people. A lot of them end up posting on this forum because their code doesn't work properly, or stops working when an upgrade is applied. A common scenario (with no offence intended to any member of the community) is a Java app that's been bundled with the jar files the developer feels are necessary. This works great until whoever owns the queue manager applies maintenance which makes those jar files incompatible. If the admin updates the client installation, this doesn't help this app which continues to use it's own, now non-functional version.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dtgruber |
| Posted: Wed Sep 26, 2012 8:43 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
| Quote: |
| The right direction is to either install the client or use a managed connection. |
I did as you suggested, however I still get the same error mentioned in my first post.
This is how I setup the MQQueueManger:
| Code: |
Hashtable properties = new Hashtable();
properties[MQC.CHANNEL_PROPERTY] = settings.CHANNEL_NAME;
properties[MQC.HOST_NAME_PROPERTY] = settings.HOST_NAME;
properties[MQC.PORT_PROPERTY] = settings.PORT;
properties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_MANAGED;
queueManager = new MQQueueManager(settings.QMGR_NAME, properties); |
Did I miss something?
Thanks
Dominik |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 26, 2012 8:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why use a hash table? Why not use the mqclient.ini file and a CCDT?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dtgruber |
| Posted: Wed Sep 26, 2012 8:55 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
[quote]Why use a hash table? Why not use the mqclient.ini file and a CCDT?[/quote]
Does it make a difference? I am fairly new to WMQ :/
I have used the code sample from here: [url]http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzav.doc%2Fun10490_.htm[/url]
Thanks
Dominik |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 26, 2012 9:00 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Yes, it makes a difference. For one thing, it means saving on an external initialisation file being a repetition of already existing functionality. See HERE, HERE, and most especially HERE.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dtgruber |
| Posted: Wed Sep 26, 2012 9:15 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
Ok. I see the advantages of using a client configuration file, and it might also be best practice to do so. But in terms of my problem I do not see a solution by using an mqclient.ini.
Are there any configurations that can only be made in the client config file that will make the managed client connection work?
This is just a test case that is connecting to a queue manager, putting/reading a message on/from a queue.
Dont get me wrong - if the usage of an mqclient.ini file will get me around my problem I will use it right away.
Thanks
Dominik |
|
| Back to top |
|
|
| dtgruber |
| Posted: Wed Sep 26, 2012 10:01 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
If I use a Managed Client Connection without having the WMQ Client installed - do I have to provide an mqclient.ini?
I have been going through the documentation but could not find anything pointing me towards this. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Sep 26, 2012 11:55 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| dtgruber wrote: |
| If I use a Managed Client Connection without having the WMQ Client installed - do I have to provide an mqclient.ini? |
With no WMQ Client installed there will be no mqclient.ini file created. Whether copying one from another installation, and setting the NMQ_MQ_LIB variable would work, it's not something I have ever tested. And don't forget, the documentation assumes a particular WMQ environment, i.e. WMQ is properly installed.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dtgruber |
| Posted: Thu Sep 27, 2012 1:06 am Post subject: |
|
|
Novice
Joined: 26 Sep 2012
Posts: 11
|
Thanks exerk for your input.
I have already tried using the mqclient.ini from an installation. Actually I have only found properties regarding ExitPaths values inside the .ini-file. However I still ended up with the same error.
I have also tried setting the NMQ_MQ_LIB environment variable, as you had suggested, but still no effect.
Nut I might have set it in the wrong way?:
[code]Environment.SetEnvironmentVariable("NMQ_MQ_LIB", "managed");[/code]
Thanks
Dominik |
|
| Back to top |
|
|
|
|
