VB autoinstall and register proposal, comments please... 
Author Message
 VB autoinstall and register proposal, comments please...

Hello,

I've been working on a theory and I'd like some opinions:

* Compile your application normally
* Create a ZIP file that contains all the run-time files your application
needs, including paths
* When you run your application, in the sub Main(), unZIP the runtime files
into the embedded locations, register them, and continue running your
application.

Here are the run-time files you'll need to distribute your application

PROJECT1.EXE
PROJECT1.ZIP
UNZIP.DLL
MSVBVM50.DLL

Since your application takes care of registering it's own run-time, you take
a delay hit the first time you run the application.  Otherwise, only if a
file is nuked or updated in the ZIP would the user notice any type of
delay...

I have this entire process working and it is really sweet over a network.  I
just create a shortcut to the PROJECT1.EXE and when a remote user runs the
application, it automatically installs and registers the runtime on their
system and continues the application normally.  This is a real jewel since I
can update the application or a DLL in a single spot and when a person runs
the application again, the update is automatcally installed.

I also created a program that lists all currently running processes on the
system and all "hooked" modules for that process.  I then have a button that
takes each dependent file for that process and automatically adds it to a
ZIP file.  This ZIP file is the runtime ZIP I mentioned in the scenario
above.

Comments, suggestions, beta testers?




Sat, 21 Apr 2001 03:00:00 GMT  
 VB autoinstall and register proposal, comments please...
Well for some apps your method may work, but for big apps it won't.

1. How do I know what OCXs, DLLs I need -- thats where InstallShield or even
install wizzard help
2. How about non-code files like pictures, resource files, DBs etc.
3. How about checking for space, moving files to a user defined location,
speed checks, lic checks, etc.
4. How about registry key values and lic issues
5. How about version checking date/size is not enough or how about location
on the target machine a file is dir x, but your method puts an older version
of it in z and the registers it.
6. If I have 50 DLLs/OCXs to register I have to code that into sub_main
(watseed space)and gett it up todate and bypass it on pass 2-n.

Again for very small apps this is a OK method, but it has holes for
commercial or large app distribution.

Quote:

>Hello,

>I've been working on a theory and I'd like some opinions:

>* Compile your application normally
>* Create a ZIP file that contains all the run-time files your application
>needs, including paths
>* When you run your application, in the sub Main(), unZIP the runtime files
>into the embedded locations, register them, and continue running your
>application.

>Here are the run-time files you'll need to distribute your application

>PROJECT1.EXE
>PROJECT1.ZIP
>UNZIP.DLL
>MSVBVM50.DLL

>Since your application takes care of registering it's own run-time, you
take
>a delay hit the first time you run the application.  Otherwise, only if a
>file is nuked or updated in the ZIP would the user notice any type of
>delay...

>I have this entire process working and it is really sweet over a network.
I
>just create a shortcut to the PROJECT1.EXE and when a remote user runs the
>application, it automatically installs and registers the runtime on their
>system and continues the application normally.  This is a real jewel since
I
>can update the application or a DLL in a single spot and when a person runs
>the application again, the update is automatcally installed.

>I also created a program that lists all currently running processes on the
>system and all "hooked" modules for that process.  I then have a button
that
>takes each dependent file for that process and automatically adds it to a
>ZIP file.  This ZIP file is the runtime ZIP I mentioned in the scenario
>above.

>Comments, suggestions, beta testers?





Sat, 21 Apr 2001 03:00:00 GMT  
 VB autoinstall and register proposal, comments please...

Quote:

>Well for some apps your method may work, but for big apps it won't.

>1. How do I know what OCXs, DLLs I need -- thats where InstallShield or
even
>install wizzard help

The process viewer I mentioned will give you a listing of the files that
your application uses at run-time and will even create the ZIP file for you.
Finding this out used to be a chore, I do agree with you on this, but no
more.  With the app I wrote, it's a cinch.

Quote:
>2. How about non-code files like pictures, resource files, DBs etc.

These files could also be included in the ZIP file.  Space saved because of
compression.  You can also have some logic to only overwrite them if they
don't exist so you don't stomp on modifiable files (databases, INI's etc).

Quote:
>3. How about checking for space, moving files to a user defined location,
speed checks, lic
>checks, etc.

This could be easily overcome by checking for space before extracting.

Quote:
>4. How about registry key values and lic issues

Like what? What keys are you taking about?  If you need to manipulate the
registry, why not due it before/after registration of the files.  If you are
talking about registering the ActiveX files (OCX and DLL's), this can easily
be done via code and is, of course, included in the process I was talking
about with less than 10 lines of code in Sub Main().

Quote:
>5. How about version checking date/size is not enough or how about location
>on the target machine a file is dir x, but your method puts an older
version
>of it in z and the registers it.

What I'm talking about is the "common" junk that normally goes into the
\System or \System32 folder.  You could place files anywhere, this is true,
depending what path you stored in the ZIp files.  But with a simple class I
have to read resource information, you could easily implement version
checking.

Quote:
>6. If I have 50 DLLs/OCXs to register I have to code that into sub_main
>(watseed space)and gett it up todate and bypass it on pass 2-n.

Wrong again.  It takes only about 10 lines to implement my process and with
the space you save by having your runtime in a ZIP file, you actually gain
space!  Also, if you add a runtime file, you simply add it to the ZIP file
and it'll be installed the next time the app is run.  Once you add the code
to Sub Main() you don't have to change it again...

Quote:
>Again for very small apps this is a OK method, but it has holes for

commercial or large app >distribution.

I have to disagree with you on all accounts.  Your proposed "problems" can
be easily overcome with very simple and easy coding.  In fact, the BETA I
have run this past week as had 100+ people hitting an application with
database access without an incident using this process.

If you have any other comments that actually poke holes into the process,
I'd like to hear them...



Sat, 21 Apr 2001 03:00:00 GMT  
 VB autoinstall and register proposal, comments please...

Quote:

>The process viewer I mentioned will give you a listing of the files that
>your application uses at run-time and will even create the ZIP file for

you. Finding this out used to be a chore, I do agree with you on this, but
no more.  With the app I wrote, it's a cinch.

At run tiime is too late for me, that means I have to exercise the entire
app (like running a CR report to find out the 10-15 DLLs it needs), etc. And
how about DLLs/OCXs that an app uses but I'm not allow to pass on.

Quote:
>These files could also be included in the ZIP file.  Space saved because of
>compression.  You can also have some logic to only overwrite them if they

don't exist so you don't stomp on modifiable files (databases, INI's etc).

Excuse me but I don't know any installer from SetupWIzzard to InstallShield
that distributes in a non-compress form. How about merging INIs, merging
registry, etc.

Quote:
>>4. How about registry key values and lic issues

>Like what? What keys are you taking about?  If you need to manipulate the
>registry, why not due it before/after registration of the files.  If you

are >talking about registering the ActiveX files (OCX and DLL's), this can
easily >be done via code and is, of course, included in the process I was
talking >about with less than 10 lines of code in Sub Main().

Like 1 or 100000 registry entries I want the installer to apply (or check or
change) so I don't waste code or time at runtime. Ans what if I need to
access the registry to get info or the user to put in a CD key or other user
info (name, options, etc.) If the app is monolitih then your method works,
if I need user interaction or have any hard install issues then it fails.

Quote:
>>5. How about version checking date/size is not enough or how about

location the target machine a file is dir x, but your method puts an older
ersion of it in z and the registers it.
Quote:

>What I'm talking about is the "common" junk that normally goes into the
>\System or \System32 folder.  You could place files anywhere, this is true,
>depending what path you stored in the ZIp files.  But with a simple class I

have to read resource information, you could easily implement version

Quote:
>checking.

Again what is a common location ODBC stuff does not go in system, and there
are 100s of OCXs that set up in the users or other dir not systems

Quote:
>>6. If I have 50 DLLs/OCXs to register I have to code that into sub_main

(watseed space)and gett it up todate and bypass it on pass 2-n. Wrong again.
It takes only about 10 lines to implement my process and with the space you
save by having your runtime in a ZIP file, you actually gain pace!  Also, if
you add a runtime file, you simply add it to the ZIP file and it'll be
installed the next time the app is run.  Once you add the code to Sub Main()
you don't have to change it again...

That is nice but 10 lines in main and how many in your class. And I save no
space since distribution files are almost allways compressed and in some
cases much better than a ZIP.

Quote:

>I have to disagree with you on all accounts.  Your proposed "problems" can

be easily overcome with very simple and easy coding.  In fact, the BETA I
Quote:
>have run this past week as had 100+ people hitting an application with

database access without an incident using this process.

I only touch 10% of the problems I can give you and your app would have to
change to meet my above problems. How about multiple version setup like
multiple human languages, font setups, printer driver installation, LAN
security setup, etc.

Quote:
>If you have any other comments that actually poke holes into the process,

I'd like to hear them...
Well I'll put it this way nicely I would not use such an app it is so
simplistics for a commercial app that it would never work, For small apps I
use Delphi where I don't need any install packages. For medium sized VB


Sat, 21 Apr 2001 03:00:00 GMT  
 VB autoinstall and register proposal, comments please...
If you at all understood the problem I am addressing, it has nothing to do
with replacing install applications.

This is targeted strictly at internet/intranet distribution systems.  Why
should I waste my time on a floppy disk distribution system when 99% of
software is distributed via CD or other form of mass media?  On this topic
your reponse doesn't hold up.

Upgrading DLL's is cake, if you know where and how to handle the install.
From your response I can see you have no idea on this topic or how to even
DLLRegisterServer() files from VB code.  This is why the "installsheilds"
laugh all the way to the bank.

Oh, and it only takes about 15 lines of code for the entire process to be
implemented, not thousands. Maybe if you coded it....

I have not idea what you meant by "one time" OCX dependencies....Using
Binary compilation solves this issue very simply.  Using only a single CLSID
for your OCX compiles ensures they have only one CLSID and thus only need
registered once on the destination system.

How about this scenario:

Run application from network, never having to touch the remote PC? Try that
with Installsheild or other install software.  We are having a nightmare
with this on Y2k.  I've had to upgrade and touch hundreds of PC's to
individually install newer versions.  But, the VB apps we've uses this
process on was cake to upgrade.  Freshen the ZIP on the server and when the
person ran the application, the DLL's and other junk were automatically
refreshed and registered for everyone.  One place, one fix, one solution.

Oh, and I still haven't finished upgrading Office on the PC's....

I feel for your frustration at using the "home grown" installs, been there,
done that. I've used Wise for years and still love it's scripting abilities.

I specifically designed this process to get out of the mind set of
continually installing and uninstalling stuff on a massive scale.  In my
last job, this "running from server with no runtimes" concept was fact
because the shop was using Delphi, however, my latest job uses VB and we all
know what a nightmare distributing and maintaining all those files can be.
The process viewer I created automatically creates the ZIP file I mentioned
in my original message of all the hooked runtime files your application
needs to run.  No more shotgun distributions or  "send everything and pray"
it works.

This process is aimed specifically at giving VB developers the same ease of
running an application that Delphi programmers have known since v1.0.

At least if you are going to comment, make sure that it is intelligent.

I don't have time to waste rebutting useless dribble...

Quote:

>I like those betas ... It's a good idea, of course. But seriously, how many
>thousands lines will you implement to take care of all *real* problems like
>: upgrade or not a DLL version, show dialogs, reboot, upgrade a DLL AFTER
>reboot (for OLE ones for instance), build floppy disks (taking care of bad
>sectors, etc.), save templates, define only *one time* the OCX
dependancies,
>etc, etc, etc. I use now the famous (but sometimes problematic) Install
>Shield because I did these kind of "home setups", and VB's wizard's too,
and
>after them I was ... disgusted. I won't change back now. But, because you
>don't like computers if you're not curious (or brain damaged) I would be
>glad to beta this end-of-millenium idea.
>Sylvain


>>I've been working on a theory and I'd like some opinions:
>Comments, suggestions, beta testers?



Sat, 21 Apr 2001 03:00:00 GMT  
 VB autoinstall and register proposal, comments please...
I like those betas ... It's a good idea, of course. But seriously, how many
thousands lines will you implement to take care of all *real* problems like
: upgrade or not a DLL version, show dialogs, reboot, upgrade a DLL AFTER
reboot (for OLE ones for instance), build floppy disks (taking care of bad
sectors, etc.), save templates, define only *one time* the OCX dependancies,
etc, etc, etc. I use now the famous (but sometimes problematic) Install
Shield because I did these kind of "home setups", and VB's wizard's too, and
after them I was ... disgusted. I won't change back now. But, because you
don't like computers if you're not curious (or brain damaged) I would be
glad to beta this end-of-millenium idea.
Sylvain


Quote:
>I've been working on a theory and I'd like some opinions:

Comments, suggestions, beta testers?


Sun, 22 Apr 2001 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. VB autoinstall and registeration, comments please...

2. VB autoinstall and registration, comments please...

3. VB 3 -> VB4, Comments please

4. Comments about VC++ versus VB please?

5. VB/ActiveX/DHTML - comments please

6. VB/ActiveX/DHTML - comments please

7. Register problems, VB Setup dont register HTML.OCX, cant load or register

8. Proposal to any VB programmers

9. Error occurred while registering ocx - please, please help.

10. Autoinstall

11. Comments please on automatic backup and compact routine

12. Locking, can anyone please comment

 

 
Powered by phpBB® Forum Software