Danimal
asked on
Deploying VB Apps
I have a general question about deploying VB apps to run on a variety of platforms.
I gather this is a complex issue, yes? no?
I ran into a problem deploying a VB app built on my XP Pro machine, when I tried putting it onto a Windows 98. My installation package included a DLL that would not run on Windows 98. The specific DLL is the Microsoft C Runtime Library (msvcrt.dll). I assume this is just one example of the general problem of managing VB apps to run on a variety of platforms.
I assume there must be some well-known basic approach to managing this problem. Can anyone provide the ABCs for how to do this?
As always, any information will be gratefully appreciated.
Regards,
-Dan
I gather this is a complex issue, yes? no?
I ran into a problem deploying a VB app built on my XP Pro machine, when I tried putting it onto a Windows 98. My installation package included a DLL that would not run on Windows 98. The specific DLL is the Microsoft C Runtime Library (msvcrt.dll). I assume this is just one example of the general problem of managing VB apps to run on a variety of platforms.
I assume there must be some well-known basic approach to managing this problem. Can anyone provide the ABCs for how to do this?
As always, any information will be gratefully appreciated.
Regards,
-Dan
ASKER
That is good to know I am not completely uninformed to think this is a tough issue.
But, there must be some standard way of dealing with this, yes? It is that standard approach I am looking for.
But, there must be some standard way of dealing with this, yes? It is that standard approach I am looking for.
Welcome to "dll hell" :(
ASKER
I thought I noticed a sign saying "dll hell" as I entered into this question.. lol :-)
I have a feeling I got off fairly easy with my dll problem this morning.....
....still no suggestions on the basics for coping?
Software companies seem to ship software that installs ok....how do they do it?
I have a feeling I got off fairly easy with my dll problem this morning.....
....still no suggestions on the basics for coping?
Software companies seem to ship software that installs ok....how do they do it?
Deploy Ur Program on Win 98
resulting setup file will work 'EASily' on XP
as Package & deployment wizard will not over write New DLLs
resulting setup file will work 'EASily' on XP
as Package & deployment wizard will not over write New DLLs
Bahnass, not a bad idea but i think you did want to say:
"package" your app in win98, is that right?
Anyway, sometimes the setup program doesn't likes to install some dll (in fact, msvcrt.dll is one of them), if they are in use.
Maybe that dll is backward compatible but since it is in use... ( and i hope that setup not overwrites new one with old one!!)
"package" your app in win98, is that right?
Anyway, sometimes the setup program doesn't likes to install some dll (in fact, msvcrt.dll is one of them), if they are in use.
Maybe that dll is backward compatible but since it is in use... ( and i hope that setup not overwrites new one with old one!!)
Other way could be not package that dll since it is present on almost any Windows OS ("Done" by Bill Gates, i mean)
>Software companies seem to ship software that installs ok
No, they have many problems.
>But, there must be some standard way of dealing with this, yes?
MS standard way is ... to break their own COM rules. You don't want to go that way.
If there is a known conflict (newer version of some component is not compatible with previous version) - the best way is:
- give older version in setup package and provide newer version of the component via your web site
Companies often go the other route - "always install the last version of everything and force users to do the same" but that can break other people's software.
No, they have many problems.
>But, there must be some standard way of dealing with this, yes?
MS standard way is ... to break their own COM rules. You don't want to go that way.
If there is a known conflict (newer version of some component is not compatible with previous version) - the best way is:
- give older version in setup package and provide newer version of the component via your web site
Companies often go the other route - "always install the last version of everything and force users to do the same" but that can break other people's software.
ASKER
ameba, I think you are starting to get at what I am looking for. However, I want to make sure I understand:
Almost any software I install on my puter runs fine. I basically never have a problem. I am running XP Pro. That fits with what you are saying, because I have all the latest stuff (at least for now)?
People running Windows 98 run into probs with new software all the time?
Regarding the practice of always giving the older version in setup package....what happens if someone has a newer version on their machine already? The installation will skip that file? How can you rely on the installer to do that and not replace the newer version with the older one?
One more thing: what is the reason for putting the latest version of the dlls on your website? How does that help your customers?
Almost any software I install on my puter runs fine. I basically never have a problem. I am running XP Pro. That fits with what you are saying, because I have all the latest stuff (at least for now)?
People running Windows 98 run into probs with new software all the time?
Regarding the practice of always giving the older version in setup package....what happens if someone has a newer version on their machine already? The installation will skip that file? How can you rely on the installer to do that and not replace the newer version with the older one?
One more thing: what is the reason for putting the latest version of the dlls on your website? How does that help your customers?
Look into using the Visual Studio Installer. With this you can include the WinNT or Win98 (or what ever) drivers and only install the ones that apply to the OS you are installing in.
This selective install is controlled using the "Condition" field for the file you are trying to install.
If your DLL is an ActiveX DLL there may be more issues and late binding may be required (using CreateObject) If it is a standard DLL and the WinNT version is not named the same as the Win98 version you will have to do some conditional compiling and make 2 different executables to release (not sure on any way to conditionally declare different dll files without creating 2 or more exe files.
If you end up with more than one exe, you can use the "Condition" field to install the proper version in your single installer pack.
This selective install is controlled using the "Condition" field for the file you are trying to install.
If your DLL is an ActiveX DLL there may be more issues and late binding may be required (using CreateObject) If it is a standard DLL and the WinNT version is not named the same as the Win98 version you will have to do some conditional compiling and make 2 different executables to release (not sure on any way to conditionally declare different dll files without creating 2 or more exe files.
If you end up with more than one exe, you can use the "Condition" field to install the proper version in your single installer pack.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the intro to the topic....
just what I was looking for....
...sounds like a lot of bad news...
just what I was looking for....
...sounds like a lot of bad news...
Thanks!
I wish I had a clear answer for you, other than to say yes it is a complex issue. Supposedly to be improved by .net technology though.