VB6 Service Pack 5 2

[wawanz]

Hi...I just installed Service Pack 5 on my VB6. My question is:
Let's say I have a VB6 application (aaa.exe) running on 50 pc's (Windows 2000). I compiled that aaa.exe using VB6 without the Service Pack. What if I made enhancements to that aaa.exe then compiled it using VB6 SP5, can I just replace the old aaa.exe with the new one? Or do I have to create a new package using the VB6 SP5 then re-install it on the 50 pc's?

Thanks

 

[johnwm]

wawanz
I notice that you haven't as yet marked any of the answers to your 28 questions as helpful/valuable. If you are not getting the right answers, read faq222-2244 to see how to get better answers. If you have found answers to be valuable, read faq 222-2244, especially para 15, to see how to acknowledge them.

For this one the safe answer is to create a new package, uninstall the old app and then install the new one. If the new package has been compiled on a new service pack you will almost certainly need the updated DLLs etc on your clients, which a new package will provide

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'If we're supposed to work in Hex, why have we only got A fingers?'

 

[ArtieChoke]

I would say it depends - are you using any non-intrinsic controls? If not, you might be okay - possibly only the VB run-time file will need to be updated. I know when we went from nothing to SP3 we had to do a reinstall.

You'll know for sure when you run it on one of the machines!

Do you really have it on 50 machines? I put all my program files on the network, so nothing ever gets installed on a user's machines except for registering activex dlls and maybe ocx files. But they still live on the network. That way, any update is done in one place - and only re-registration is needed.

 

[wawanz]

johnwm: I thought so too, that's why for this particular customer I always use my non-SP5 VB6. So I develop using 2 computers. But I'll try my SP5 .exe on one of those 50 machines to be sure. Thanks for reminding me about the 28 questions.

ArtieChoke: Yes, I installed my application on 50+ machines (it's a call center application)...Would you be so kind in explaining to me in details on how you put your program files on the network, so you need to update only in one place?

Thanks guys!

 

[ArtieChoke]

You need these things to make it work from a network:

[ul]
[li]A share everyone can map to (or just have access privileges) to run the program from.[/li]

[li]Put the exe file and all run-time files (dlls, vb runtime, ocx, etc.) on the share in the same directory.[/li]

[li]Create a shortcut to the exe file, set the startup directory to the exe directory (use an "UNC" for the path name) and distribute that to the users.[/li]

[li]And the tricky part - a way to register any dll files the program needs auto-magically , rather than with an install program[/li]
[/ul]

Check out FAQ faq222-4724 for a way to do it. Note: this method will make you declare every dll file you want to register in the program, since you'll have to name them explicitly and hard-code the path name (which can be bad if your share directory server changes names). If you add dlls, you'll have to add more declares. If you don't have any dll files or just a couple, it should work fine.

I created a programmatic way (with a little help from some VB code sites) that can take an input file of dll file names and register all of them at one time. It depends on having an unchanging share area name to locate the dll files. Now that we're using DFS, it's not a big deal any more - but before, I still needed to hard-code the name of the server - and when it changed - I had to change the code - doh!

One other thing to be aware of - and this goes for installation programs also - the user must have the ability to modify the registry to be able to register the files.

Let me know if you need any more clarification.

"I think we're all Bozos on this bus!" - Firesign Theatre