Xcopy Install of VB Classic Application

  • Thread starter Thread starter Charles Law
  • Start date Start date
C

Charles Law

Hi chaps

I realise that this is a .NET group, but please don't shoot me down quite
yet. I looked in the vb classic groups and there seems to be so little
activity there that I was not hopeful of a prompt response, and I figure
that the guys here probably came from vb classic anyway. So, apology over
....

I have an application in vb6, and I want to install it on a system that has
never seen the vb development environment, or any of the vb runtime files
(unless they are part of the OS). For reasons best known only to my client,
it should be an xcopy install.

I can identify all the files needed to run the application, but when I copy
them all to the application directory, the program starts and then falls
over with an ActiveX unable-to-create-object type of error. I am guessing
that this is because one or more of the files need to be registered, but
aren't.

The first question is: what actually happens when I run regsvr32 on a dll or
ocx? I imagined that an entry was added to the registry so that the file can
be found, but perhaps there is more to it than that. The file is in the
application directory, but that does not appear to be sufficient. What else
happens, and can I avoid registering the file(s)?

The second question is: is there any way to perform an xcopy installation of
a vb6 application?

TIA

Charles
 
Hi Ken

Thanks for the reply.

I might be able to get away with the VB runtime being a pre-requisite of the
installation, but it might be more difficult when it comes to component
controls of the application.

I appreciate that ActiveX controls need to be registered, but I would like
to understand the registration process a bit better. What actually happens
when a control is "registered"?

I have tried placing all required files in a single directory, but I get
ActiveX Unable to create object ~. If I register the controls I still get
the same thing, so there must be more to it than that. If I create a setup
package with the SDW then when I run it all is well.

Charles
 
If an ActiveX file has system dependencies in the way of dll files, the
VB6 packager picks up on these, and will include the dll files with the
instalation package. There could be some key VB dll files your
application is looking for that haven't been included. If you use the
packager that comes with VB6, you can build a dependency file to get a
list of all the files that your application needs.

T
 
Hi Tom

That is actually how I generated the list of files to copy. I looked at the
cab file created by the SDW and manually copied all the files that it
contained to the target directory.

Charles
 
The second question is: is there any way to perform an xcopy
installation of a vb6 application?
Click to expand...

In addition to the libraries you have installed and registered, remember
to copy and run MDAC_TYP.EXE if you have ADO code. Also, if you are installing
on Win 98 or before, remember to install DCOM. If your application uses office
automation, you will have even more libraries to worry about. In general,
the simpler the application, the easier it will be to install. You may want
to try a "hello XCopy" project and see what it takes to get it running with
a manual installation process first and then start adding your application's
components. Just tell your client that you will be adding a week worth of
work to get them this feature where-as using an installer, you could have
it delivered faster and at lower cost. Also, an xcopy install won't set up
your desktop/start menu icons, so you will need to do that yourself.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
 
Thanks for the good points Jim.

Charles


Jim Wooley said:
In addition to the libraries you have installed and registered, remember
to copy and run MDAC_TYP.EXE if you have ADO code. Also, if you are
installing on Win 98 or before, remember to install DCOM. If your
application uses office automation, you will have even more libraries to
worry about. In general, the simpler the application, the easier it will
be to install. You may want to try a "hello XCopy" project and see what it
takes to get it running with a manual installation process first and then
start adding your application's components. Just tell your client that you
will be adding a week worth of work to get them this feature where-as
using an installer, you could have it delivered faster and at lower cost.
Also, an xcopy install won't set up your desktop/start menu icons, so you
will need to do that yourself.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
Click to expand...
 
Charles,
Have you tried to use side-by-side approach of distribution?
What is it? When your application depends on any third party stuff it looks
for them in the directories which contained those files on your development
machine. But you do not place them there when you create a folder for your
app and put all files there.
In case of side-by-side your application will start to look for each file it
depends on in the application directory first and only after it doesn't find
it moves to other directories (system32 etc).
To have side-by-side you need to create a file (just empty text file) with
the same name as your EXE and add .local to the end of the name. Put that
file in the same folder as your EXE. For instance your EXE has the name
MyApplication.exe. You need to create a file with the name
MyApplication.exe.local
It solves many other problems, like for instance after your regular
installation of your program with some third party ocx or dll, there is
another installation of the other program with the same ocx but older
version. It will break your installation. With side-by-side distribution
it's not happening.

Al
 
vul said:
Charles,
Have you tried to use side-by-side approach of distribution? []
To have side-by-side you need to create a file (just empty text file) with
the same name as your EXE and add .local to the end of the name.
Click to expand...

Does this apply to a standard VB exe or only to .net apps? The OP is
referring to a VB6 program.
James
 
Hi Al

Thanks for the reply. I haven't heard of this for a VB6 application so, as
James says, I wonder if this applies to .NET?

I realise that this is not the intended place to ask VB classic questions,
but I thought I would reach a wider audience here.

Charles
 
Back
Top