| Author |
Message
|
| PeterGibbons |
 Posted: Mon Mar 15, 2004 11:06 am Post subject: Unable to load DLL (amqxcs2.dll) |
 |
|
Newbie
Joined: 15 Mar 2004
Posts: 5
|
Hello,
We are currently using MQSeries 5.3 with CSD6. After doing some testing with CSD6, we got the following problem
Unable to load DLL (amqxcs2.dll).
at IBM.WMQ.MQTrace.xcsInitialize(UInt16 scope, UInt16 attributes, Byte[] charName, Byte[] charPrefix, xcsHPOOL& hPool)
at IBM.WMQ.MQTrace..cctor()
When we tried to instantiate a MQQueueManager object within an ASP.NET web application
qMgr = new MQQueueManager("", channelName, connectionName);
Can anybody offer any suggestions or help?
Thanks,
Andrew |
|
| Back to top |
|
 |
| JasonE |
| Posted: Mon Mar 15, 2004 12:53 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
At a guess you dont have the fp6 amqmdnet.dll registered in the GAC and instead we are picking up an earlier one. Try deregistering and reregistering your amqmdnet.dll
Similarly make sure you have MQ on the path, and that you only have one copy of amq* and mq* dll's and those are in the MQ install dir \bin |
|
| Back to top |
|
|
| PeterGibbons |
| Posted: Mon Mar 15, 2004 1:06 pm Post subject: Unable to load DLL (amqxcs2.dll) |
|
|
Newbie
Joined: 15 Mar 2004
Posts: 5
|
| Thanks, we'll verify that we've done that correctly. |
|
| Back to top |
|
|
| PeterGibbons |
| Posted: Tue Mar 16, 2004 11:44 am Post subject: Unable to load DLL (amqxcs2.dll) |
|
|
Newbie
Joined: 15 Mar 2004
Posts: 5
|
Hello,
We have uninstalled MQSeries entirely off this developers machine and installed MQSeries client 5.3 with csd6. He then registered amqmdnet.dll in the GAC and when we tried to run his test web application, we got the same error:
Unable to load DLL (amqxcs2.dll).
at IBM.WMQ.MQTrace.xcsInitialize(UInt16 scope, UInt16 attributes, Byte[] charName, Byte[] charPrefix, xcsHPOOL& hPool)
at IBM.WMQ.MQTrace..cctor()
When we tried to instantiate a MQQueueManager object within the ASP.NET web application.
We verified that he compiled with the right version of amqmdnet.dll and that he isn't calling the wrong version of the dll. He told me that he's had success with building and running console apps, and windows apps, but he gets this particular problem with his web application. Any suggestions are much appreciated.
Thanks,
Andrew |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Mar 16, 2004 2:45 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
What environment variables does an ASP.NET app have - ie is the MQ bin directory on the PATH for the whole system (not current user). I dont know if you can query the PATH within a .net app (havent tried), but if you can it might be worth dumping it. Note the .net interfact still calls the C interface.
Do the samples work ok (eg. nmqsput) from a command line ok?
Were any FDC's cut (I assume not, I dont think we have got into the C layer yet, I think we cant locate amqxcs2.dll) |
|
| Back to top |
|
|
| MikeClark |
| Posted: Tue Mar 16, 2004 3:20 pm Post subject: Me, too... |
|
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
I have the same problem. I have the amqmdnet.dll in the gac, but the rest of all the dlls are not installed, apparently. In order to avoid the problem of strong name associated with the current version of the amqmdnet.dll, I manually installed that dll in the gac, thus interrupting the normal install of the rest of the classes.
I think the solution might be to re-install the Classes for .NET, and this time let the full install complete. Since amqmdnet.dll is already in the gac, it won't try to re-install it, but will install everthing else where they are supposed to be.
I'll try this and report back if it made the difference.
Gosh, what would it take for IBM to fix the problem? A year of programmer time, or nobody's complaining loud enough?
Oh, well.
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Mar 16, 2004 4:34 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Quote: |
| but the rest of all the dlls are not installed, apparently |
Can you explain what you mean by that. If you get the amqmdnet.dll you should also have the full client or server install image. In your case, the client image. There is no other way to get that dll!
The .NET support is not fully managed, ie it drops down to C to call into MQ in both client and server mode. Therefore the .NET dll (amqmdnet is the whole assembly) is not a standalone entity, and required the MQ infrastructure, starting with the core amqxcs2.dll
The install problem you hit was different - The MSI install modified the dll as it was told to. This was a 'bug' which is fixed when fp6 macv gets updated (soon). |
|
| Back to top |
|
|
| MikeClark |
| Posted: Tue Mar 16, 2004 4:57 pm Post subject: Explanation |
|
|
Apprentice
Joined: 17 Feb 2004
Posts: 27
Location: Olympia, WA
|
In order to get the uncorrupted amqmdnet.dll I had to terminate the full installation of the MQ Client after it had copied the source, but before it installed everything. This was to avoid having it attempt to install amqmdnet.dll into the GAC, which process is broke in the current release of the MACVEnUs -- see http://www.ibm.com/Search?v=11&lang=en&cc=zz&q=amqmdnet.dll. Clear so far?
Anyway, having stopped the install at that point gave me an uncorrupted amqmdnet.dll, which I then manually installed into the GAC (successfully). What I didn't do at that time (since I guess I didn't think it was necessary) was go on to re-do the whole MACVEnUs installation so as to get the rest of the .dll's installed. The rest of the .dll's, as you point out, are NOT CLR assemblies and must be installed properly (including being put into the registry) in order to work with amqmdnet.dll.
Now, per my earlier post, I have now finished re-installing MACVEnUs (just an hour ago), and now my Visual Studio .NET installation of MQ Client works! Well, that's putting it a little strongly, since I have not yet gotten a successful message put onto the remote MQ server.
However, I have gotten MQ compcodes and reasoncodes in response to attempts to communicate with the server, which is progress! 
_________________
"...a long habit of not thinking a thing wrong, gives it a superficial appearance of being right..." [Tom Paine] |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Mar 17, 2004 1:35 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Ah! I understand, thanks. I was assuming (always fatal!) that you had completed the install and got the corrupt dll, then reran the unpack to get the new dll. Apologies... |
|
| Back to top |
|
|
| PeterGibbons |
| Posted: Tue Mar 30, 2004 8:37 am Post subject: Unable to load DLL (amqxcs2.dll) |
|
|
Newbie
Joined: 15 Mar 2004
Posts: 5
|
Hello,
We opened a PMR for our situation, and IBM seemed sure that our problem with being unable to load amqxc2.dll was related to the path. IBM was concerned with the number of occurances of amqxcs2.dll and imqb23vn.dll, and where they were located. What I finally ended up doing
was renaming any occurances of amqxcs2.dll and imqb23vn.dll (besides the occurances in the bin directory) to amqxcs2.dll.old and imqb23vn.dll.old, so that they wouldn't be called. When the developer recompiled his application, we no longer had any errors. I then renamed all the .old files back to their original names and got him to recompile again. The application worked fine again. So this problem was not caused by csd6, but was something to do with the developers machine. Thanks for your help JasonE. I posted my solution to our problem in case anyone encounters a similar situation.
Andrew |
|
| Back to top |
|
|
| Sandor Takats |
| Posted: Wed Apr 28, 2004 1:52 pm Post subject: |
|
|
Newbie
Joined: 28 Apr 2004
Posts: 3
|
Hi Gang,
I don't believe that amqmdnet.dll has to be in the GAC at all. I do believe that the MQ bin directory has to be in your path and that the account that your application runs under has to have read priveleges to that bin directory.
So, for example, if you are running an ASP.NET application, the Websphere MQ\bin directory has to allow the ASPNET account read access.
The above is based on first-hand experience.
Good Luck!
_________________
The Sandman |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Apr 29, 2004 1:20 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
As per the memo.ptf, amqmdnet does not 'have' to be in the GAC - You can for example have an app.exe.config xml file which points to the amqmdnet.dll file.
The 'advantage' of putting it in the GAC is for tools to automatically find it
The 'disadvantage' is that you might forget to update the GAC when you install a fixpack or fix from IBM |
|
| Back to top |
|
|
| mcanavan |
| Posted: Wed Dec 15, 2004 4:49 pm Post subject: |
|
|
Newbie
Joined: 15 Dec 2004
Posts: 2
|
I can confirm that for CSD08/XP/IIS/dotNET 1.1
o Register amqmdnet.dll in GAC
o Add assembly in dotNET Project
o Allow .NET user read access to MQSeries\bin directory
Fixes this problem |
|
| Back to top |
|
|
| Rish |
| Posted: Fri Jan 14, 2005 2:27 pm Post subject: Solved, specific to ASP.net |
|
|
Newbie
Joined: 14 Jan 2005
Posts: 1
|
I spent a whole day trying to figure this out.
I was able to build a .Net console application that successfully instantiated
the Queue Manager object, but ASP.Net apps still gave me the message:
Unable to load DLL (amqxcs2.dll).
It turns out that the search paths for DLLs in ASP.Net versus the console
application were different. The console application was correctly looking
for amqxcs2.dll (and its dependencies) in
c:\Program Files\IBM\Webs...\bin
ASP.Net was only looking in windows\system32, c:\, and a few others.
I used filemon from www.systeminternals.com to check this out.
SOLUTION:
I haven't figured out why ASP.net isn't looking in the paths specified
by my System Path, but for now, I just copied all of the DLLs in the
Websphere\bin directory into my windows\system32 directory and all
worked fine after that.
There's a more in depth discussion of the ASP.net search algorithm and
where it's getting its path information from in this google thread:
http://groups.google.ca/groups?hl=en&lr=&threadm=MPG.185c275541b8116098968b%40news.newsguy.com&rnum=6&prev=/groups%3Fq%3DDLLNotFoundException%2Basp.net%26hl%3Den
Peace.
Rishan |
|
| Back to top |
|
|
| JasonE |
| Posted: Mon Jan 17, 2005 1:38 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Copying amq* dlls outside of the MQ bin directory is one of the things which causes no end of problems - dont do it - Fix the cause of the problem. The problem is you'll apply a fixpack at some point in time and you MQ system will stop working and you'll spend ages working out why.
Trust me - I see so many times where the root cause of all a users trouble is an amq*.dll which is back level because someone copied it outside the bin directory...
That article seems to imply the search path is basically the system path not the user path, which is what I would have expected for a service. If the mq bin directory is on the user path then services cant pick this up. |
|
| Back to top |
|
|
|
|
