Mike Williams said:
Yes, but the VB5 runtime (and the VB6 runtime) are both less than 2 MB and
are, as far as I am aware, present by default on all standard
installations of Win XP upwards and are in any case easily
redistributable. You certainly cannot say the same for the various
variants of the net framework!
Well, but distribution of the Classic VB runtime was a problem when PCs
didn't have an internet connection and software was distributed primarily on
floppy disks back in the last decade.
What you have just described is a complete mess. I would much sooner be
clear on exactly what is required and have a definite "No" instead of all
this "maybe, possibly, yes but only if . . ." stuff.
Well, I just didn't want to go into detail. There is definitely no "No"
because the compatiblity I described is defined ("by design") behavior.
We were promised that dotnet would fix all the Classic Visual Basic "DLL
Hell" for us, but instead it has just made matters worse. I was rather
hoping for a system such as I believe Delphi to be (or perhaps to have
been before they too moved down the dotnet road) where in Delphi you could
compile an app and the compiled exe would be completely self contained and
would run on whatever machine you threw it at (at least that's how I
understood Delphi to have worked). But Micro$oft have not done that.
DLL hell in the days of Classic VB was not a VB-only problem. It has been
caused by the operating system which didn't provide sufficient mechanisms
for DLL versioning and loading. This has changed in the meantime, and
Windows XP and newer versions of Windows allow XCOPY deployment of almost
self-contained packages of files (EXE, DLL, OCX, ...). Windows now contains
even something like an unmanaged GAC (WinSxS). That's all not really
related to Classic VB.
