469,609 Members | 1,634 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,609 developers. It's quick & easy.

Xcopy Install of VB Classic Application

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
May 24 '06 #1
9 1944
Hi,

As long as all the activex controls used by the vb6 application are
registered and the vb6 run time is installed it should work.

http://www.microsoft.com/downloads/d...displaylang=en

Ken
------------------
"Charles Law" <bl***@nowhere.com> wrote in message
news:OI**************@TK2MSFTNGP02.phx.gbl...
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

May 24 '06 #2
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
"Ken Tucker [MVP]" <vb***@bellsouth.net> wrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl...
Hi,

As long as all the activex controls used by the vb6 application are
registered and the vb6 run time is installed it should work.

http://www.microsoft.com/downloads/d...displaylang=en

Ken
------------------
"Charles Law" <bl***@nowhere.com> wrote in message
news:OI**************@TK2MSFTNGP02.phx.gbl...
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


May 24 '06 #3
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

Charles Law wrote:
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
"Ken Tucker [MVP]" <vb***@bellsouth.net> wrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl...

Hi,

As long as all the activex controls used by the vb6 application are
registered and the vb6 run time is installed it should work.

http://www.microsoft.com/downloads/d...displaylang=en

Ken
------------------
"Charles Law" <bl***@nowhere.com> wrote in message
news:OI**************@TK2MSFTNGP02.phx.gbl...

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



May 24 '06 #4
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
"tomb" <to**@technetcenter.com> wrote in message
news:s2*******************@bignews4.bellsouth.net. ..
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

Charles Law wrote:
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
"Ken Tucker [MVP]" <vb***@bellsouth.net> wrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl...
Hi,

As long as all the activex controls used by the vb6 application
are registered and the vb6 run time is installed it should work.

http://www.microsoft.com/downloads/d...displaylang=en

Ken
------------------
"Charles Law" <bl***@nowhere.com> wrote in message
news:OI**************@TK2MSFTNGP02.phx.gbl...

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


May 24 '06 #5
> The second question is: is there any way to perform an xcopy
installation of a vb6 application?


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
May 24 '06 #6
Thanks for the good points Jim.

Charles
"Jim Wooley" <ji*************@hotmail.com> wrote in message
news:24*************************@msnews.microsoft. com...
The second question is: is there any way to perform an xcopy
installation of a vb6 application?


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

May 24 '06 #7
vul
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

"Charles Law" <bl***@nowhere.com> wrote in message
news:e2*************@TK2MSFTNGP02.phx.gbl...
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
"tomb" <to**@technetcenter.com> wrote in message
news:s2*******************@bignews4.bellsouth.net. ..
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

Charles Law wrote:
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
"Ken Tucker [MVP]" <vb***@bellsouth.net> wrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl.. .

Hi,

As long as all the activex controls used by the vb6 application
are registered and the vb6 run time is installed it should work.

http://www.microsoft.com/downloads/d...displaylang=en

Ken
------------------
"Charles Law" <bl***@nowhere.com> wrote in message
news:OI**************@TK2MSFTNGP02.phx.gbl.. .

>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
>
>
>


May 24 '06 #8
"vul" <aa*@optonline.net> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
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.


Does this apply to a standard VB exe or only to .net apps? The OP is
referring to a VB6 program.
James
May 24 '06 #9
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
"vul" <aa*@optonline.net> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
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

"Charles Law" <bl***@nowhere.com> wrote in message
news:e2*************@TK2MSFTNGP02.phx.gbl...
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
"tomb" <to**@technetcenter.com> wrote in message
news:s2*******************@bignews4.bellsouth.net. ..
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

Charles Law wrote:

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
"Ken Tucker [MVP]" <vb***@bellsouth.net> wrote in message
news:%2***************@TK2MSFTNGP02.phx.gbl. ..

>Hi,
>
> As long as all the activex controls used by the vb6 application
> are registered and the vb6 run time is installed it should work.
>
>http://www.microsoft.com/downloads/d...displaylang=en
>
>Ken
>------------------
>"Charles Law" <bl***@nowhere.com> wrote in message
>news:OI**************@TK2MSFTNGP02.phx.gbl. ..
>
>>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
>>
>>
>>
>



May 25 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Ryno Rijnsburger | last post: by
6 posts views Thread by Cristian Suazo | last post: by
4 posts views Thread by Matt Anderson | last post: by
2 posts views Thread by Bruce Schechter | last post: by
1 post views Thread by Dave | last post: by
12 posts views Thread by Alan M Dunsmuir | last post: by
1 post views Thread by lizii | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.