| Author |
Message
|
| PeterPotkay |
 Posted: Sun Dec 19, 2004 8:02 am Post subject: Deploying VB.NET apps |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Trying to teach myself VB.NET.....
On my PC, I see that in the bin directory for my Solution, I have my app's .exe, something ending in pdb, as well as amqmdnet.dll. I used the CSD08 version of amqmdnet.dll. Does that mean other users of my app need to be at CSD08 for their MQClient, or can I somehow build the installer setup so that when they install my app, it installs the version of amqmdnet that I want (CSD08), and overrides any other version they have, and even works if they are at an old version of the MQClient, like 5.3.0.2?
I have my program working on my machine, and I now want to build a SetUp project so others can use this program. The books I have tell me to use the SetUp Project Wizard, but I don't have that option, since I only have Visual Basic Standard Edition.
What do I need to do to build an Installer program that I can distribute if I don't have the SetUp Project Wizard?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Dec 19, 2004 9:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter,
My understanding is that .NET is just a wrapper for the underlying C client.
So in a nutshell you need a client at CSD08 for the full CSD08 functionality.
Now if you do not need any of the additional functionality it's a test at your own risk.
Anyway let us know how it went.
Thanks
F.J. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Dec 19, 2004 10:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I guess what happens is that the amqmdnet.dll calls out to the undelying MQClient code on the machine it is running on. What I wonder is is there a way for my installer program to insure that the app uses the CSD08 version of amqmdnet.dll that I bundle with the package, or will it use a locally installed version of that dll, that may be older and thus may have bugs in it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Dec 19, 2004 10:36 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi Peter,
Each CSD usually has a way to do a silient install. I would suggest that 'your application installer' embed and launch a silient install of the CSD as part of your application's install process.
Make sure you warn the user that you are doing this!! 
If you need a really good and free installer application, then I suggest you look at Inno Setup by JRSoftware:
http://www.jrsoftware.org/isinfo.php
Also, bundling MQ DLLs is not a good idea.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Dec 19, 2004 10:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Thanks Roger I'll check that out.
Why is not a good idea to bundle the mq dll?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Dec 19, 2004 10:59 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Unless there is something very particular about the DLL (i.e. Java JNI call to MQ DLL 02, 03, 04, 05, ...) then I would not bundle it.
You may get into issues when the next release of MQ comes out that this DLL is incompatible in binding or client mode with the new release.
At client site, they purchased RightFax software and it has MQ 5.1 DLLs included and it is a pain to remember to overwrite those with the current MQ DLLs.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Dec 19, 2004 3:13 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
There was discussion in this forum about distributing MQ DLLs with the application. I am not sure if the licensing terms allow you to do this or not.
I agree with what Roger said.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Dec 20, 2004 6:38 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Peter,
I also am self teaching myself .Net. What I usually do when I deploy is to add a readme file with the requirements in there. I also have my code check the local machine registry to see if the MQ Client is isnatlled or not and spit out a message if it isn't. My findings so far is that as long as the client is CSD07 or above even thought my programs were developed on CSD08 the work with CSD07 just fine. Unless you are using something that is CSD08 specific I think CSD07 should also work. Of course anything lower then CSD07 and all bets are off!
HTH
Kevin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Dec 20, 2004 3:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
So thats a good point about not bundling the dll. If a user has CSD X on his machine, he should expect the MQ app he just installed to run with that version of the dll.
I can take it upon myself to make sure the destination machine is at a certain version of MQ by looking at the reg and maybe even autoinstalling a CSD as Roger suggested with a warning.
The thing is that I registered amqmdnet.dll in my Solution Explorer in the IDE. (under References, I clicked Add, then browsed to where on my PC I had amqmdnet.dll).
When I ran my app, it stuck a copy of the amqmdnet.dll into the app's bin folder. So now it looks like even on my own pc, the app is using the copy of amqmdnet.dll that is in bin, and not the "real" one.
When I look at the File System Editor after I created a Deployment project, I see a copy of the amqmdnet.dll got stuck in the Application Folder as well.
So it looks like for some reason when I am building my installer doohickie, it seems to want to stick in a copy of the amqmdnet. How do I prevent that, and make the installed app on the destination machine look for the local version of the amqmdnet.dll on the destination machine?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| swood |
| Posted: Wed Jan 12, 2005 9:20 am Post subject: |
|
|
Novice
Joined: 10 Dec 2004
Posts: 20
|
.NET dlls don't need to be registered.
The .NET runtime will search in this order, for the correct version of the dll that the app was supposed to use when compiled:
1. GAC(Global Assembly Cache)
2. Local folder the app is running in
3. Recursively check sub folders of the folder the app is running in.
This process is called Probing.
This only works with .NET dlls. For .NET to use a non .NET dll it must be "wrapped" in a .NET wrapper (created by Visual Studio when adding a reference to said dll). IF the .NET runtime needs non .NET dlls it should use the ones that are in the registry. I believe that the wrapper contains the information from the registry to find the non .NET dll although I can't find an article on this.
Here is a link to read from msdn.microsoft.com.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp
_________________
I don't know as much as I wish I did. |
|
| Back to top |
|
|
|
|
