Deploying Access 2007 Runtime / developer extensions / basic MSI installer questions

[ARC]

I'm currently looking at the access developer extensions for creating an MSI
installer package for a 2007 runtime app. Couple of observations and
questions.

1) Doesn't look like we have the ability to set a packaged file to always
overwrite, or never overwrite, unless I'm missing something. This could be a
sticking point, as I would always want the program to overwrite on
re-installing, but NEVER the back end database. I have a few more files
where I would want to Always overwrite. Am I missing something simple? I
tried right-clicking on a file in the "additional files" box, but no such
options.

2) What good is the "Feature information"? Ideally, I'd like to have an
install option for Full version with blank back-end databases, or an option
during install to only install a new program file, and no back-end
databases. I guess I would need to have 3 installs: 1) Full (program and
database), 2) Program Only, 3) Dedicated Server only (back-end database
files only)

3) The ability to add extra registry keys seems to point to a solution of
adding the program path as a trusted location, so the user doesn't get the
macro disabled warnings. However, if you choose "Program Files", for some
reason it says: ("All Users - Read Only for Vista"). Does that mean you can
no longer install programs to c:\Program Files for vista? (Since I'm coming
from Access 97 runtimes, I'm a bit out of date here, I admit)

4) This may be the biggie: For adding a few .dll's to your install package
(I have an e-mail .dll for an e-mail add-in util), and I have a registration
..dll (this registration .dll will write the key to the win registry, which I
hope isn't a problem in Vista). But I don't see a note that additional files
will be self-registered. Do they get registered automatically in the win
registry?

That's about it for now, and thank in advance,

Andy

[Tom van Stiphout]

On Sat, 08 Sep 2007 02:41:00 GMT, "Tony Toews [MVP]"
<tt****@telusplanet.netwrote:

You are partially right. There are two kinds of DLLs: classic DLLs
don't need to (and can't) be registered. They just need to be in the
path and will automatically be loaded by Windows.
ActiveX DLLs need to be registered, using regsvr32.exe
I would expect that most setup program generators are smart enough to
recognize this, and register the dll while installing it.
OCXes are very close to ActiveX DLLs and do indeed require
registration.

-Tom.
<clip>

>

>>4) This may be the biggie: For adding a few .dll's to your install package
(I have an e-mail .dll for an e-mail add-in util), and I have a registration
.dll (this registration .dll will write the key to the win registry, which I
hope isn't a problem in Vista). But I don't see a note that additional files
will be self-registered. Do they get registered automatically in the win
registry?

Not quite sure what you mean by self registering. DLLs don't need registering I
don't think. You just need to reference them. OCXs do need registering. However I
sure could be wrong here.

Tony

[Sascha Trowitzsch]

Hi,

I analyzed the msi created by the extensions reverse engineering it.
That's what I can say:

"ARC" <an**@andyc.comschrieb im Newsbeitrag
news:nd*****************@nlpi061.nbdc.sbc.com...

I'm currently looking at the access developer extensions for creating an MSI
installer package for a 2007 runtime app. Couple of observations and
questions.

1) Doesn't look like we have the ability to set a packaged file to always
overwrite, or never overwrite, unless I'm missing something. This could be a
sticking point, as I would always want the program to overwrite on
re-installing, but NEVER the back end database. I have a few more files where
I would want to Always overwrite. Am I missing something simple? I tried
right-clicking on a file in the "additional files" box, but no such options.

IMO there's no possibility to do file checking for existing versions. AKAIK any
existing file will be overwritten.

2) What good is the "Feature information"? Ideally, I'd like to have an
install option for Full version with blank back-end databases, or an option
during install to only install a new program file, and no back-end databases.
I guess I would need to have 3 installs: 1) Full (program and database), 2)
Program Only, 3) Dedicated Server only (back-end database files only)

It's not possible to specify more than one msi feature. Likewise no facility to
specify userdefined conditions.

3) The ability to add extra registry keys seems to point to a solution of
adding the program path as a trusted location, so the user doesn't get the
macro disabled warnings. However, if you choose "Program Files", for some
reason it says: ("All Users - Read Only for Vista"). Does that mean you can no
longer install programs to c:\Program Files for vista? (Since I'm coming from
Access 97 runtimes, I'm a bit out of date here, I admit)

In general there's no need here to add a reg key for your trusted location. The
extensions automatically adds this key for the place you assign for the root
install folder.
Beyond this I haven't tested under Vista. I have no experience with the
extensions behaviour under it.

4) This may be the biggie: For adding a few .dll's to your install package (I
have an e-mail .dll for an e-mail add-in util), and I have a registration .dll
(this registration .dll will write the key to the win registry, which I hope
isn't a problem in Vista). But I don't see a note that additional files will
be self-registered. Do they get registered automatically in the win registry?

No. Definitely no selfregister flag is set for activex components.
You would have to run a batch file or something else after setup to register
your components.

Overall I can only see the extensions as a solution for very simple databases.
They do not supersede the use of a professional installation system.

Ciao, Sascha

[ARC]

Thanks, Sascha!

I pretty much figured I would have to go with Sagekey's Acc2007 script, but
prior to putting down the $$, I thought I'd take a look at the developer
extensions.

Worth a shot, but no go.

Thanks again,

Andy

[ARC]

By the way, Sascha, one feature that impressed me, and I thought would be
very slick, was the ability to prompt the user to download the runtime. That
would save bunches of space on my domain host! It's too bad, as I'm sure the
Sagekey script won't have that feature.

Ciao to you too,

Andy
"Sascha Trowitzsch" <[e-mail] in message
news:fb**********@online.de...

Hi,

I analyzed the msi created by the extensions reverse engineering it.
That's what I can say:

"ARC" <an**@andyc.comschrieb im Newsbeitrag
news:nd*****************@nlpi061.nbdc.sbc.com...

>I'm currently looking at the access developer extensions for creating an
MSI installer package for a 2007 runtime app. Couple of observations and
questions.

1) Doesn't look like we have the ability to set a packaged file to always
overwrite, or never overwrite, unless I'm missing something. This could
be a sticking point, as I would always want the program to overwrite on
re-installing, but NEVER the back end database. I have a few more files
where I would want to Always overwrite. Am I missing something simple? I
tried right-clicking on a file in the "additional files" box, but no such
options.

IMO there's no possibility to do file checking for existing versions.
AKAIK any existing file will be overwritten.

>2) What good is the "Feature information"? Ideally, I'd like to have an
install option for Full version with blank back-end databases, or an
option during install to only install a new program file, and no back-end
databases. I guess I would need to have 3 installs: 1) Full (program and
database), 2) Program Only, 3) Dedicated Server only (back-end database
files only)

It's not possible to specify more than one msi feature. Likewise no
facility to specify userdefined conditions.

>3) The ability to add extra registry keys seems to point to a solution of
adding the program path as a trusted location, so the user doesn't get
the macro disabled warnings. However, if you choose "Program Files", for
some reason it says: ("All Users - Read Only for Vista"). Does that mean
you can no longer install programs to c:\Program Files for vista? (Since
I'm coming from Access 97 runtimes, I'm a bit out of date here, I admit)

In general there's no need here to add a reg key for your trusted
location. The extensions automatically adds this key for the place you
assign for the root install folder.
Beyond this I haven't tested under Vista. I have no experience with the
extensions behaviour under it.

>4) This may be the biggie: For adding a few .dll's to your install
package (I have an e-mail .dll for an e-mail add-in util), and I have a
registration .dll (this registration .dll will write the key to the win
registry, which I hope isn't a problem in Vista). But I don't see a note
that additional files will be self-registered. Do they get registered
automatically in the win registry?

No. Definitely no selfregister flag is set for activex components.
You would have to run a batch file or something else after setup to
register your components.

Overall I can only see the extensions as a solution for very simple
databases.
They do not supersede the use of a professional installation system.

Ciao, Sascha

[Tony Toews [MVP]]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote:

>You mean in the "Windows 95 days," because Windows 2000 was the
first to implement read-only Program Files for users only.

And this all gets back to developers running as administrators when they should be
running as users. Which would find all these problems.

<hypocrite>Which I really have to start doing myself Real Soon Now. </hypocrite>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[AnandaSim]

On Sep 9, 4:20 am, "David W. Fenton" <[e-mail]>
wrote:

Well, put it in the user's profile, and you can get to it with the
%USERPROFILE% environment variable. So, if your app is in

A lot depends on the pain and the local IT SOE. With one workplace, I
prefer to put it in c:\myapp because that is not locked down or better
still \\server\networkshare\myapp if it is a common location or \
\server\networkshare\usersprofile so I can save myself legwork.

There is one problem with personalising the myapp location - some
roles keep changing user accounts (you know what I mean) and you soon
have myapp distributed over several user accounts and some users
change workstations so you then have myapp duplicated or not
replicated over Y user accounts * Z workstations...

1. You gotta to work with the SOE.
2. You gotta work with the least deployment and maintenance/update
pain

There are certainly a variety of better practices - you just have to
look back after 6 months and see how many helpdesk or issue calls
sourced by deployment.

Ananda

[David W. Fenton]

AnandaSim <An*******@gmail.comwrote in
news:11**********************@o80g2000hse.googlegr oups.com:

On Sep 9, 4:20 am, "David W. Fenton"
<[e-mail]:

>Well, put it in the user's profile, and you can get to it with
the %USERPROFILE% environment variable. So, if your app is in

A lot depends on the pain and the local IT SOE. With one
workplace, I prefer to put it in c:\myapp because that is not
locked down

That's non-standard, then, as nothing in the root of C: should be
write accessible to users.

or better
still \\server\networkshare\myapp if it is a common location or \
\server\networkshare\usersprofile so I can save myself legwork.

There is one problem with personalising the myapp location - some
roles keep changing user accounts (you know what I mean) and you
soon have myapp distributed over several user accounts and some
users change workstations so you then have myapp duplicated or not
replicated over Y user accounts * Z workstations...

Why not put it in All Users?

1. You gotta to work with the SOE.
2. You gotta work with the least deployment and maintenance/update
pain

There are certainly a variety of better practices - you just have
to look back after 6 months and see how many helpdesk or issue
calls sourced by deployment.

On a workstation where you want all users to have access to the app,
the proper location for it is in the All Users folder.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tony Toews [MVP]]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote:

>Why not put it in All Users?

I don't know if that's supported in Windows Vista. I know a user can no longer create
shortcuts in the All Users >Start Menu >Programs. The Auto FE Updater failed on
that in testing so I disabled that option when in Vista.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[David W. Fenton]

"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:6h********************************@4ax.com:

"David W. Fenton" <XX*******@dfenton.com.invalidwrote:

>>Why not put it in All Users?

I don't know if that's supported in Windows Vista. I know a user
can no longer create shortcuts in the All Users >Start Menu >>
Programs. The Auto FE Updater failed on that in testing so I
disabled that option when in Vista.

You're right in that users have not had permissions on All Users
since at least Win2K (ran into it yesterday with a client who was
trying to delete shortcuts on her user desktop that were stored in
All Users).

I wasn't thinking.

If a machine has multiple users, perhaps an admin should install the
program and change the permissions for the folder in All Users that
is used to store the app.

On the other hand, once an admin is touching each desktop and
changing permissions, you might as well put your app anywhere you
want.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tony Toews [MVP]]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote:

>>>Why not put it in All Users?

I don't know if that's supported in Windows Vista. I know a user
can no longer create shortcuts in the All Users >Start Menu >>
Programs. The Auto FE Updater failed on that in testing so I
disabled that option when in Vista.

You're right in that users have not had permissions on All Users
since at least Win2K (ran into it yesterday with a client who was
trying to delete shortcuts on her user desktop that were stored in
All Users).

Hmm, that's a good point. Maybe the Auto FE Updater also can't update shortcuts in
All Users >Start Menu >Programs in Win XP or Win 2000. I must admit to having
only tried that when running as administrater. <whack Ok,wrist slapped. I'll have
to do a better job of testing that in the future.

I also need to add better checking to ensure a requested operation actually worked.
Such as double checking that a shortcut was actually created/updated with the right
data and ensure that files were actually copied down with the right size and date.

>I wasn't thinking.

And neither was I.

>If a machine has multiple users, perhaps an admin should install the
program and change the permissions for the folder in All Users that
is used to store the app.

On the other hand, once an admin is touching each desktop and
changing permissions, you might as well put your app anywhere you
want.

Right. So as far as I'm concerned I don't have a problem with the original scenario
where x users * y systems might have that many FEs scattered around on hard drives
through out the office. Using WAG (wild *ssed guesses) say 10 users on one system
with a 10 Mb FE means 100 Mb wasted. I can live with that.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[ARC]

While we're discussing vista, I have a very old registration .dll I use
called RedRegistration. It still functions perfect for me, and I'm wondering
if this causes any problems on vista. It writes the user key to the windows
registry under HKEY_LOCAL_MACHINE\SOFTWARE\<Company Name>, then on app
startup it reads the registry values under that key.

Thannks!

Andy

[David W. Fenton]

"ARC" <an**@andyc.comwrote in
news:2d****************@newssvr21.news.prodigy.net :

While we're discussing vista, I have a very old registration .dll
I use called RedRegistration. It still functions perfect for me,
and I'm wondering if this causes any problems on vista. It writes
the user key to the windows registry under
HKEY_LOCAL_MACHINE\SOFTWARE\<Company Name>, then on app startup it
reads the registry values under that key.

You need to examine the permissions on that registry key. It should
be read-only for regular users, write for only admins (and maybe
power users).

This is not new, either -- it's been that way since Win2K (i.e.,
1999).

You can answer these questions yourself by simply creating a
user-level logon and running your installer. That will quickly show
you what fails.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/