Can I deploy Access Runtime without using the Packaging wizard?

[Max Moor]

Hi All,
I have an Access 2002 application to deploy. I own Office 2002, so I'm
legal to redistribute Access Runtime.

I've been using Tarma installer instead of the packaging wizard to make
my setup package. This has been to make customization and installation of
extra things easier. Lately, I've become concerned that I'm not deploying
Access Runtime correctly, though.

I've been looking for a reference guide that will tell me how to deploy
Access Runtime without the packaging wizard. I want to know what files I
need to ship for the references below. Can anyone point me to one?

- Max




Visual Basic For Applicationss
Microsoft Access 10.0 Object Library
OLE Automation
Microsoft ActiveX Data Objects 2.5 Library
Microsoft ADO Ext. 2.8 for DLL and Security
Microsoft DAO 3.6 Object Library

 

[Albert D. Kallal]

I've been using Tarma installer instead of the packaging wizard to make

my setup package. This has been to make customization and installation of
extra things easier. Lately, I've become concerned that I'm not deploying
Access Runtime correctly, though.

Well, what I do is build the runtime install with the package wizard. This
install is JUST the runtime. I THEN build the rest of the install using
inno. This allows me to setup shortcuts on the desktop (they don't work
correctly in a2003).

So, my Inno install (and in your case Tarma) simply first installed the
runtime package created by the package wizard. I simply do a silent
install..but, the progress bar does show...I use:


FileName: {app}\setup.exe; Parameters: "/qb"

So, what I do is use inno to package up the "setup" + \files folder that the
package wizard creates.

Doing this means that the basic correct runtime install is handled by the
wizard. however, for everything else (my mde front
end...shortcuts.....checking if the runtime exists on the machine..etc., I
do all of this from inno.

OF course once the initial install is done, and any updates simply don't
bother with the packagewizard, and FURTHER DO NOT include the runtime. So,
updates to the front end are small, easy...and my users actually download
them from a simple static web page. Here is a series of screen shots as how
this looks:

http://www.kallal.ca/ridestutorialp/upgrade.html

I've been looking for a reference guide that will tell me how to deploy
Access Runtime without the packaging wizard. I want to know what files I
need to ship for the references below. Can anyone point me to one?

Hum, I don't have a reference, but I well avoided what to include by
actually allowing the wizard to create the runtime install. However, I do
NOT include my mde, or shortcut stuff in the runtime wizard install. In
effect, I ONLY use the package wizard to pack up the runtime..... (I think
you have to include at least one file for the wizard to work..I just include
a readme.txt file).

 

[Jerry Porter]

I think you need Office XP Developer to legally distribute the runtime.
Maybe that's what you meant.

 

[Max Moor]

Well, what I do is build the runtime install with the package wizard...

Hi Albert,
I'll give this a shot. Letting Microsoft handle the Microsoft part
does seem the smartest way. Thanks for the advice!

- Max

 

[Max Moor]

I think you need Office XP Developer to legally distribute the runtime.
Maybe that's what you meant.

Hi Jerry,
Yes, I misspoke in a tired moment. I have XP developer.

TTFN

 

[Max Moor]

Hi Again Albet,
I'm wondering if you can give me a bit more direction...

You'd mentioned using the packaging wizard just to do the runtime
install, using just a text file fo the package's file. How do I do that?

When I run the packaging wizard, I put in the name of my front-end on
the first screen, and the wizard scans for dependencies. Isn't it (the front
end) part of the package at that point?

If I use something other than my front-end, like a text file, there
aren't any dependencies. The wizard won't package runtime properly, will it?
What should I be doing?

Regards, Max

 

[Albert D. Kallal]

If I use something other than my front-end, like a text file, there

aren't any dependencies. The wizard won't package runtime properly, will
it?
What should I be doing?

That is true, but then again, I kind of assumed that you don't have any more
dependencies then a basic mde file requites.

I *suppose* you could include a tiny simple(sample) mde file.

Do note that in a2003, the ability of the package wizard to find/know about
dependences has BEEN removed. In other words, the a2003 runtime is a basic
install, and all of the required dependences for your application are
included.

As for using the calendar control, listview, treeview? Well, that is simple:
the a2003 includes the 6 supported activeX controls, EVEN if you don't use
them. So, you are FREE to use the activeX controls that are supported. There
is a KB article that outlines the supported activeX controls supported
somewhere (but, it is the 6 basic ones). To be fair, most activeX controls
work with ms-access. So, if you are using any 3rd party activeX controls,
and start to use the A2003 pw, you will be disappointed..as it DOES NOT add
additional dependencies like the a2002 package wizard does.

In a way, I like the a2003 wizard, as it simply includes the bases install
that you need for ms-access. It been years since I attempted to add ANY
special controls, or references in my packaged applications. By keeping
things simple, then I reduce/eliminate broken installs. I even gave up on
using the calendar control, and now use my own built in drop-in sub form...
(A client of mine was using some accounting package, and every time they
installed the software, it broke the calendar control in my software - that
was the last straw, and the last time I ever was to be bitten my dll hell -
something that VB6, and windows developers have had to deal with for years).
So, I just avoided the whole mess, and don't use any thing but built in
controls now...

However, I doubt you are using any 3rd party controls. And, if you are, then
use the Tarma to install them...not the packwizard.

The references included should be ONLY the same as when you create a BLANK
new mdb, and then check the references. You do NOT want a reference to
anything such as word/outlook/excel etc. (you use late binding for that
stuff).

Last, but not least, I not used the a2002 packawage wizard, but only a97,
and now I use a2003. So, for a2003, including a dummy text file, or a mdb
really don't make any difference now, since as mentioned, a2003 does not
check for dependencies anymore....

 

[Max Moor]

That is true, but then again, I kind of assumed that you don't have any
more dependencies then a basic mde file requites.

Thanks for the pointers, Albert. I'm going to work on this today. I'll let
you know how it comes out.

Max

 

[Max Moor]

FileName: {app}\setup.exe; Parameters: "/qb"

Hi Albert,
Sorry to bother you again, but I'm a bit stuck. I've built the runtime
install with the packaging wizard, and added that to my Tarma build for the
app. Everything looks good, until I try to run the runtime setup silently.

I've been testing it on the command line. I tried running it using
"Setup.exe /qb". It gives me the "Copying Files" message box, but then fails
with "Invalid command line parameters. Unable to continue."

I've tried everything I can think of to get it to spit out its
acceptable arguments (/?, /h, /help, etc), but it doesn't like anything I
try.

Are there special tricks I need to use to make the setup.exe
bootstrapper accept, then pass on, command line arguments?

- Max

 

[Albert D. Kallal]

I've been testing it on the command line. I tried running it using

"Setup.exe /qb". It gives me the "Copying Files" message box, but then
fails
with "Invalid command line parameters. Unable to continue."

I've tried everything I can think of to get it to spit out its
acceptable arguments (/?, /h, /help, etc), but it doesn't like anything I
try.

I not used the Trama installer. I would assume that you FIRST ensure that
you un-pack the runtime to a directory
(I used to use c:\mdbRuntime)

You then execite

c:\mdbruntime setup.exe /qb

Try a test script were you un-pack the runtime, and do a setup /qb from the
command line...and see how that goes....

Also, try it on a clean machine with out ms-access (virtual pc is a gift
horse for testing this stuff..and is now free).