| Author |
Message
|
| kolban |
 Posted: Fri Jun 28, 2002 1:52 pm Post subject: MQSeries.NET package |
 |
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Folks,
I have released the first version of my MQSeries.NET package. This package allows Microsoft .NET programmers to access all the features of MQSeries. It makes coding MQ applications in languages like C# very, very easy.
The distribution includes the MQ.dll assembly, documentation and samples.
At this time, I am not yet releasing source for the assembly.
It is provided on a complete "asis" basis and no formal support will be provided.
For more information and download, see MQSeries.NET |
|
| Back to top |
|
 |
| kolban |
| Posted: Wed Jul 03, 2002 5:44 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Folks,
I am looking for some feedback on this package. I continue to enhance it and have just added full PCF support for performing adminstrative actions against the queue managers.
Are there any immediate wish list items that need addressed?
Expect a refresh release in 2-3 weeks with all the new functions.
Neil |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 03, 2002 5:50 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Neil,
I haven't actually used C# before. Do I need to purchase the entire Visual Development Studio to get the compiler, or can I buy just the C# compiler separately?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| kolban |
| Posted: Wed Jul 03, 2002 7:23 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
One can download the whole Microsoft .NET framework SDK which includes libraries, compilers and other tools for free at
.NET download
Although Visual Studio .NET provides a complete IDE framework that makes .NET programming a breeze, everything one needs include docs and tools are available here. Just no where near as nicely integrated. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 03, 2002 7:50 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well, now I've got 2 projects for the long weekend. Play with this API, and try out the trial version of Reconda's product.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Peter Heggie |
| Posted: Tue Jul 09, 2002 5:30 am Post subject: Is MQ server required to be on developers workstation? |
|
|
Newbie
Joined: 09 Jul 2002
Posts: 1
Location: Syracuse, NY
|
Can this be used as an encapsulation of MQ calls, such that it acts as a proxy? So the developer can bring in a reference to it and/or can remotely instantiate it on the MQ server machine from his/her workstation?
Peter |
|
| Back to top |
|
|
| Ramchip |
| Posted: Thu Jul 11, 2002 6:17 am Post subject: |
|
|
Newbie
Joined: 11 Jul 2002
Posts: 1
|
Neil,
It appears that this framework requires the MQSeries server installed to make the MQM.DLL library available. Would it be possible to create a client-only version?
Thanks!
Rick |
|
| Back to top |
|
|
| Prophet |
| Posted: Fri Jul 19, 2002 11:06 pm Post subject: server library problem |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
First off, thank you for creating this  . We were utilizing the MQAX libraries for a large application and the threading issues with that library were beginning to cause serious bottlenecks. We were looking at having to wrap the API ourselves when we ran across this little gem.
However, I havent had a chance to test it out yet. I am experienceing the same problem as Ramchip. I dont have the server software installed on my dev machines nor application servers and would really like to see it autodetect which library to use.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
| kolban |
| Posted: Sat Jul 20, 2002 6:05 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Guys, apologies for the delay ... (been vacationing ...) ... I'm on it now, please expect an update in the new few days.
Neil
PS... as a workaround, copy mqic32.dll to mqm.dll and all should work as expected. |
|
| Back to top |
|
|
| sidy |
| Posted: Sun Jul 21, 2002 5:44 pm Post subject: Cannot get MQSeries .NET assembly to work |
|
|
Newbie
Joined: 10 Jul 2002
Posts: 5
Location: Australia
|
Howdy all,
I installed the .NET dll (MQ.DLL) but Visual Studio 7 cannot see it, so when I run the MQ samples I get an error:
C:\temp\MQSamples\Simple Put\SimplePut.cs(20): The type or namespace name 'MQ' could not be found (are you missing a using directive or an assembly reference?)
Any ideas ?
_________________
==================
Sid Young
Brisbane
Australia
================== |
|
| Back to top |
|
|
| sidy |
| Posted: Sun Jul 21, 2002 8:06 pm Post subject: |
|
|
Newbie
Joined: 10 Jul 2002
Posts: 5
Location: Australia
|
Howdy all,
Using Visual Studio I now get this error when compiling:
I am using the Beta 2 version of Visual Studio .NET
------ Build started: Project: SimpleRequest, Configuration: Debug .NET ------
Preparing resources...
Updating references...
Performing main compilation...
error CS0518: The predefined type 'System.Byte' is not defined or imported
Build complete -- 1 errors, 0 warnings
Building satellite assemblies...
---------------------- Done ----------------------
Build: 0 succeeded, 1 failed, 0 skipped
_________________
==================
Sid Young
Brisbane
Australia
================== |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Mon Jul 22, 2002 10:11 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| sidy wrote: |
Howdy all,
Using Visual Studio I now get this error when compiling:
I am using the Beta 2 version of Visual Studio .NET
------ Build started: Project: SimpleRequest, Configuration: Debug .NET ------
Preparing resources...
Updating references...
Performing main compilation...
error CS0518: The predefined type 'System.Byte' is not defined or imported
Build complete -- 1 errors, 0 warnings
Building satellite assemblies...
---------------------- Done ----------------------
Build: 0 succeeded, 1 failed, 0 skipped |
Hi Sid,
I should have scrolled down on this thread before replying to your listserver question... 
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| sadamahan |
| Posted: Mon Jul 22, 2002 11:20 am Post subject: |
|
|
Newbie
Joined: 23 May 2002
Posts: 6
Location: Simi Valley,CA
|
|
| Back to top |
|
|
| kolban |
| Posted: Mon Jul 22, 2002 1:26 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Its a very, very good question. I am not yet sure where my MQSeries package is going.
I have used the MQSeries Java API as a model for the MQSeries.NET work which has a subtely different model than that of the MQSeries COM bindings. In addition, the MQSeries.NET package provides symbolic definitions for constants and is written in C# as a completly managed environment.
Obviously, the IBM supported functions (COM bindings) should be used for production activity since there is currently zero support for my releases and work continues on an as-is, best effort basis only.
I haven't tried a performance comparison yet. I'd be interested in seeing two applications that perform the same task but using the different APIs and see if there are any performance implications. |
|
| Back to top |
|
|
| Prophet |
| Posted: Mon Jul 22, 2002 2:06 pm Post subject: |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
The biggest problem with the COM MQ Libraries is that they are apartment threaded. This causes some serious performance issues in applications that use the GET with wait pattern. Basically while the thread is blocked in the GET, it locks all other activating threads in the apartment.
I assume these new .NET libraries are utilizing the MQ API and mimicing the Java libraries approach? If that is so, they won't suffer the same setbacks.
Another good reason to have native .NET libraries is to avoid the overhead of COM interop. There is quite a large performance penalty associated with COM interop that can be totally avoided by using Native language bindings.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
|
|
