MSVBVM50.DLL
in [Visual Basic]
|
From: Nobody on 3 Jul 2010 12:21 "NadCixelsyd" <nadcixelsyd(a)aol.com> wrote in message news:202c20f9-13fc-4bca-80d2-217e9876c325(a)y11g2000yqm.googlegroups.com... > Why install multiple versions of DLLs when only one is > needed? Normally, the file is part of a set of files that needs to be applied as a whole, because these files interact with each other. See this article for the list of files: INFO: List of Visual Basic Run-Time Files Installed by Product http://support.microsoft.com/kb/187282 Both VB5&6 use 6 runtime files having the same file name, except for one file: msvbvm50.dll for VB5, and msvbvm60.dll for VB6. Because the runtime files are shared, you will only need to install or update msvbvm50.dll in OS'es with the VB6 runtime preinstalled. However, the proper thing to do which also covers the case when the VB5/6 runtime are not installed or included on the OS is to supply an installer that upgrades(or installs if not there already) all the six VB5 files. The installer should check for the version and only update if the file version being installed is newer, otherwise you get what's called DLL Hell. One modern installer you could use is InnoSetup. the instructions on how to use it with VB are at the link below. Just edit the "60" into "50" in "msvbvm60.dll", and it should be fine. http://www.jrsoftware.org/iskb.php?vb However, for inhouse use or for families and friends, you may want to redirect them to run this VB5 runtime installer, which updates/installs all 6 files. I am not sure if it works with the latest version of Windows though: FILE: Msvbvm50.exe Installs Visual Basic 5.0 Run-Time Files http://support.microsoft.com/kb/180071
From: ralph on 3 Jul 2010 13:14 On Sat, 3 Jul 2010 08:45:09 -0700 (PDT), NadCixelsyd <nadcixelsyd(a)aol.com> wrote: >> >> I don't have a Win7 machine handy, but jeez, what's the problem? �Nobody in >> their right mind distributes a VB application without an installation program >> anyway, and the intall program automatically installs the dependencies >> including the VM. � >> >I consider myself in my right mind, but you're entitled to your >opinion. > >I prefer the KISS approach. Why make the user go through the install >process when an EXE module can be moved into directory in the PATH >statement? The uninstall is just as quick: delete the module. > >Since my original post, I've upgraded the program from VB5 to VB6. >VB6 run-time modules are already (I believe) part of the operating >system. Why install multiple versions of DLLs when only one is >needed? > In the replies it was apparent that several ppl forgot you were talking about VB5 and not VB6. The VM for VB5 is NOT commonly included with newer O/Ss or SPs. If delivering a VB5 app then including the 5.0 VM is advisable. What you are calling a KISS approach is not always the best way. To paraphase Bruce McKinney famous quote - "It doesn't matter how fast it is (or simple) if it doesn't work." Windows applications are best installed through an Installer for several reasons which may or may not apply depending on your target. 1) To make sure the target has all the components. (Already discussed to death.) What components to include would once again depend on the target. For a known box, probably very little. For an unknown box, probably the world. :-) 2) To make insure any initial configuration is setup correctly. All Users A single user Profile? Machine specifics etc. 3) To insure the program is located in a consistent and logical (and known) location. 4) To insure the app appears as an uninstall option, and that an uninstaller is available. 5) To simply make it easier for the user - one click install, run. But, again, it depends on your target. In a shop/corporate environment I often provide two install packages. One for initial setup for admin to insure proper location and configuration, and setting up a standard image, and a second for updates (often a simple xcopy-type). [Actually the former is more often two packages - one for the box/net, and other for the user.] For friends 'n family I'll probably email the program with simple instructions and stand by with IM open to handle the questions. For a shrink-wrap package (or remote corporate sites) I'd likely build a rather bulky include all, handle all, package. But always somewhere is a formal installer lurking. You can get away with a simle copy quite often - until it goes bad. IMHO it WILL always go bad sooner or later, as you discovered. <G> -ralph
From: Tony Toews on 3 Jul 2010 22:42 On Fri, 02 Jul 2010 22:08:14 GMT, sfdavidkaye2(a)yahoo.com (David Kaye) wrote: >I'm thinking that this newsgroup is too nitpicky for my taste. I'm just lurking on this discussion but it seems to me that this is a highly technical newsgroup. Thus being a nitpickier and nitpickied is necessary to fully understand what is going on bheind the scense. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Karl E. Peterson on 6 Jul 2010 19:58 Tony Toews formulated on Saturday : > On Fri, 02 Jul 2010 22:08:14 GMT, sfdavidkaye2(a)yahoo.com (David Kaye) > wrote: > >> I'm thinking that this newsgroup is too nitpicky for my taste. > > I'm just lurking on this discussion but it seems to me that this is a > highly technical newsgroup. Thus being a nitpickier and nitpickied > is necessary to fully understand what is going on bheind the scense. Man, I love nothing better than having my ideas nit-picked! How else do you find the flaws in them? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 6 Jul 2010 20:01
on 7/3/2010, ralph supposed : > What you are calling a KISS approach is not always the best way. To > paraphase Bruce McKinney famous quote - "It doesn't matter how fast it > is (or simple) if it doesn't work." Yeahbutt, "work" is just so subjective... You can *measure* fast! <gd&r> -- ..NET: It's About Trust! http://vfred.mvps.org |