Best Installation Location on Vista

[Keith]

I have an MDE application used by several hundred people in different
parts of the world. The majority of users are of lesser experience
computer experience. The app consists of a frontend (MDE) and backend
(MDB), a help file and a key file.

To this point, I have provided users with an installation package
which installed both files into their program files folder with no
problems.

A few users are getting new computers with vista installed by default.
I personally am not using Vista but have access to a computer to test
with (just bought a new computer last fall).

I have heard that installing to program files is not working under
vista. As I understand it Vista does not grant write permission to
Program Files.

My question is, what do I need to be aware of when creating a setup
program to install this app on Vista. I have considered:

1. Installing in Program Files and then changing permissions for that
folder in the installation process (Inno setup).

2. Installing to a Documents folder, either current user or all users.

Which is the best option? Are there OTHER options for me to consider?
Please understand that this needs to be automated as most users don't
have the skill to do much more than click Setup.exe

Keith

[DavidB]

On May 25, 1:37 pm, Keith <[e-mail]:

I have an MDE application used by several hundred people in different
parts of the world. The majority of users are of lesser experience
computer experience. The app consists of a frontend (MDE) and backend
(MDB), a help file and a key file.

To this point, I have provided users with an installation package
which installed both files into their program files folder with no
problems.

A few users are getting new computers with vista installed by default.
I personally am not using Vista but have access to a computer to test
with (just bought a new computer last fall).

I have heard that installing to program files is not working under
vista. As I understand it Vista does not grant write permission to
Program Files.

My question is, what do I need to be aware of when creating a setup
program to install this app on Vista. I have considered:

1. Installing in Program Files and then changing permissions for that
folder in the installation process (Inno setup).

2. Installing to a Documents folder, either current user or all users.

Which is the best option? Are there OTHER options for me to consider?
Please understand that this needs to be automated as most users don't
have the skill to do much more than click Setup.exe

Keith

Stay away from VISTA is the best choice... :)

[Keith]

On May 25, 12:57 pm, DavidB <[e-mail]:

>
Stay away from VISTA is the best choice... :)

Unfortunately that is not an option. When average users buy a new
computer they get Vista! My users are just average people

[Tony Toews [MVP]]

Keith <Po*******@gmail.comwrote:

>2. Installing to a Documents folder, either current user or all users.

Yes. And it should be Application Data. Or rather %appdata% environment variable.
Although the %allusersprofile% would also be an option. The full path would be
something like "C:\Documents and Settings\ttoews\Application Data" on my system.
This would be for all the objects you mention.

Now the Access retail/runtime needs to be installed by an administrator so it goes
into Program Files.

And really you should be testing all this under Windows XP using a user account
anyhow. N

I need to explain this better on the Auto FE Updater pages but that's certainly been
my experience.

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/

[Albert D. Kallal]

yes, you unfortunately have to stay away from the program file folders now.

Not only are they read only, but in many cases, windows will "virtualizes"
the files, so in fact, you find multiple copies of a file (for each
user)..and, with a mdb file..that not good!!!

for inno, i am now using:

C:\Documents and Settings\All Users\Application Data\Rides

"rides" is a applaton foler lcoaton now.

in inno, this is:

[Setup]
SourceDir=c:\Documents and Settings\All Users\Application Data\Rides
AppName=Rides Reservation System
AppVerName= Rides 2.0
DefaultDirName={commonappdata}\Rides
DefaultGroupName=Rides

So, notice how commonappdata is the folder I now use.....

note that users as a general rule can't see this folder unless they turn on
the view for system, or file folders.

anyway, as a few mentioned, choose my documents, or the above folder seems
like a good one for me...

You also notice that my source directory (were I developing from) is also
that path name (I place a folder on my desktop with shortcut inside of it,
since browsing to that folder is quite time consuming.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[David W. Fenton]

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

Keith <Po*******@gmail.comwrote:

>>2. Installing to a Documents folder, either current user or all
users.

Yes. And it should be Application Data. Or rather %appdata%
environment variable. Although the %allusersprofile% would also be
an option. The full path would be something like "C:\Documents
and Settings\ttoews\Application Data" on my system. This would be
for all the objects you mention.

That would be C:\Users\ something or other on a fresh Vista install,
though, right? If you use the environment variables, you don't have
to worry about how it's mapped, of course.

On my Win2K box, I recently finally got around to moving
C:\Documents and Settings\ to D:\Users\. I intended to put it on E:,
but found out I didn't have enough space there.. In any event, any
application that hardwires to C:\Documents and Settings instead of
using the appropriate environment variables is written by an inept
programmer.

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

[David W. Fenton]

"Albert D. Kallal" <Pl*******************@msn.comwrote in
news:2kb6i.227116$DE1.28492@pd7urf2no:

yes, you unfortunately have to stay away from the program file
folders now.

Not only are they read only, but in many cases, windows will
"virtualizes" the files, so in fact, you find multiple copies of a
file (for each user)..and, with a mdb file..that not good!!!

for inno, i am now using:

C:\Documents and Settings\All Users\Application Data\Rides

"rides" is a applaton foler lcoaton now.

in inno, this is:

[Setup]
SourceDir=c:\Documents and Settings\All Users\Application
Data\Rides AppName=Rides Reservation System
AppVerName= Rides 2.0
DefaultDirName={commonappdata}\Rides
DefaultGroupName=Rides

So, notice how commonappdata is the folder I now use.....

Is it not the case that Vista virtualizes C:\Users\ to look like
C:\Documents and Settings? I think you should use environment
variables instead of hardwiring them, and let the OS decide what the
exact location is.

Does anyone know if there's a document with MS's guidelines for this
somewhere? I'm not sure what to look for on Google.

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

>Yes. And it should be Application Data. Or rather %appdata%
environment variable. Although the %allusersprofile% would also be
an option. The full path would be something like "C:\Documents
and Settings\ttoews\Application Data" on my system. This would be
for all the objects you mention.

That would be C:\Users\ something or other on a fresh Vista install,
though, right? If you use the environment variables, you don't have
to worry about how it's mapped, of course.

No, not C:\Users. That's more for user data. On Windows XP the My Documents folder
is actually under C:\Documents and Settings\ttoews\My Documents and is the
equivalent. However the folder to install an Access FE MDB/MDE would be
C:\Documents and Settings\ttoews\Application Data. Thus the user can't get to it
from the My Documents folder on Windows Explorer. They have to unhide hidden
folders to get to the the Application Data.

I would guess. I'm not that familiar with Vista yet.

Maybe, maybe not. I do have Windows Vista installed on a Virtual PC but I'm having a
bit of trouble navigating the bowels.

In any event, any
application that hardwires to C:\Documents and Settings instead of
using the appropriate environment variables is written by an inept
programmer.

Exactly. And presumably the Inno setup and other setup routines fully support the
use of environment variables or their equivalent.

Note that while the Auto Fe Updater appears to use the environment variables such as
%appuser% it actually uses the Windows API calls to pull in the appropriate values.

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/

[Albert D. Kallal]

Is it not the case that Vista virtualizes C:\Users\ to look like

C:\Documents and Settings? I think you should use environment
variables instead of hardwiring them, and let the OS decide what the
exact location is.

Does anyone know if there's a document with MS's guidelines for this
somewhere? I'm not sure what to look for on Google.

Yes, there is a good document here:

http://go.microsoft.com/fwlink/?linkid=81232

From the above:

<quote>
Prior to Windows Vista, many applications were typically run by
administrators. As a result, applications could freely read and write system
files and registry keys. If standard users ran these applications, they
would fail due to insufficient access.

Windows Vista improves application
compatibility for standard users by redirecting writes (and subsequent file
or registry operations) to a per-user location within the user's profile.
For example, if an application attempts to write to C:\Program
Files\Contoso\Settings.ini, and the user does not have permissions to write
to that directory, the write will get redirected to
C:\Users\Username\AppData\Local\VirtualStore\Progr am
Files\contoso\settings.ini.

For the registry, if an application attempts to
write to HKEY_LOCAL_MACHINE\Software\Contoso\ it will automatically get
redirected to
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MA CHINE\Software\Contoso or
HKEY_USERS\UserSID_Classes\VirtualStore\Machine\So ftware\Contoso.

</quote>

So, what this means is that if a user tries to write to a file with non
admin privileges, you have multiple COPIES of the that file present on the
computer!!! Windows virtualises these files writes if you not a admin user.
For a .ini file, that not a huge problem, but for text files, or a mdb file,
you wind up with multiple copies of the file. And, if you browse (or your
program code) even opens up that file location, you are in fact opening up a
VIRTURAL location..and you code WILL NOT know this!! (nor will the user
interface shows this). I think for ms-access people, the issue is if we
use/store info in a .ini file....

As another side note, the inno installer actually does select the correct
install
folder (so, if I installed on a win 2000 box, or even a windows 98 box, then
the correct target install location is resolved by the installer.
(in this case I used
DefaultDirName={commonappdata}\Rides

So, inno does change/choose the correct directory "commonappdata" based on
the user (and os) your running. (eg: you can install for "all users", or
just the current user).
Anyway, we can ignore the inno installer for the time being!

So, the problem is that if you have a mdb file in something like:

c:\program files\MyCoolApp\myap.mdb

If you have admin privileges, then myap.mdb is read write. If you don't have
admin, then a COPY OF this file is made, and it is virtualized into a user
dir.

However, I not 100% educated on program files virtualization, and as far as
I
know, the virtualization ONLY occurs to .ini, .exe, and .dll files (and, to
boot, the registry is also virtualized in this case...so, users can't write
to the original registry).

I not tested this, but I do not think that mdb files get virtualized. Since
"mdb" files don't get virtualized, then my assumption right now is that the
mdb file will be read only by default.

And, a user could right click on the shortcut, and set it to be run with
admin settings.

To be honest, I been using

c:\Documents and Settings\All Users\Application Data\Rides

I using above because that what seems to work for me, and it present in both
xp and vista....
and it is read/write.

So, my choice of location was anything I could find that would be
read/write..
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[missinglinq via AccessMonster.com]

Since you're talking about running Access dbs on Vista machine, you need to
read this notice from Micro$oft's Knowledge Base:

When you open or are using a Microsoft Office Access database on a computer
that is running Windows Vista, you may encounter one or more of the following
issues:
• Access appears to stop responding.
• Access responds very slowly.
• Access exits unexpectedly or crashes.
• An event that resembles the following is logged in the Application log:

See the entire article and MS's suggested workarounds at:

http://support.microsoft.com/?kbid=935370

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200705/1

[David W. Fenton]

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

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

>>Yes. And it should be Application Data. Or rather %appdata%
environment variable. Although the %allusersprofile% would also
be an option. The full path would be something like
"C:\Documents and Settings\ttoews\Application Data" on my
system. This would be for all the objects you mention.

That would be C:\Users\ something or other on a fresh Vista
install, though, right? If you use the environment variables, you
don't have to worry about how it's mapped, of course.

No, not C:\Users. That's more for user data.

Huh? All the MS documentation I can find says that C:\Users is the
equivalent of C:\Documents and Settings as the location for user
profiles.

On Windows XP the My Documents folder
is actually under C:\Documents and Settings\ttoews\My Documents
and is the equivalent. However the folder to install an Access
FE MDB/MDE would be C:\Documents and Settings\ttoews\Application
Data. Thus the user can't get to it from the My Documents folder
on Windows Explorer. They have to unhide hidden folders to get
to the the Application Data.

And in Vista, that would be:

C:\Users\ttoews\Application Data

Vista virtualizes C:\Users as C:\Documents and Settings so that
applications that hardwire the path as %SystemDrive%\Documents and
Settings\ will still work.

I would guess. I'm not that familiar with Vista yet.

Maybe, maybe not. I do have Windows Vista installed on a Virtual
PC but I'm having a bit of trouble navigating the bowels.

The documentation I've read says that C:\Users is the new
C:\Documents and Settings.

>In any event, any
application that hardwires to C:\Documents and Settings instead of
using the appropriate environment variables is written by an inept
programmer.

Exactly. And presumably the Inno setup and other setup routines
fully support the use of environment variables or their
equivalent.

Note that while the Auto Fe Updater appears to use the environment
variables such as %appuser% it actually uses the Windows API calls
to pull in the appropriate values.

And here's code to do that for you in Access:

http://www.mvps.org/access/api/api0054.htm

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

[David W. Fenton]

"Albert D. Kallal" <Pl*******************@msn.comwrote in
news:DMp6i.232404$aG1.7846@pd7urf3no:

To be honest, I been using

c:\Documents and Settings\All Users\Application Data\Rides

I using above because that what seems to work for me, and it
present in both xp and vista....
and it is read/write.

In Vista, my understanding is that C:\Documents and Settings is not
realy there. Perhaps it's a junction (i.e., symbolic link), but all
the data really goes in C:\Users.

If you write your apps and installers to use the environment
variables, then you don't really have to worry about it.

Which was my point.

Access code for getting the locations using Windows APIs:

http://www.mvps.org/access/api/api0054.htm

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

[David W. Fenton]

"missinglinq via AccessMonster.com" <u28780@uwewrote in
news:72d43ebb11d7d@uwe:

Since you're talking about running Access dbs on Vista machine,
you need to read this notice from Micro$oft's Knowledge Base:

When you open or are using a Microsoft Office Access database on a
computer that is running Windows Vista, you may encounter one or
more of the following issues:
? Access appears to stop responding.
? Access responds very slowly.
? Access exits unexpectedly or crashes.
? An event that resembles the following is logged in the
Application log:

See the entire article and MS's suggested workarounds at:

http://support.microsoft.com/?kbid=935370

That's the SMB 2 problem and can be solved by turning off SMB 2 on
either the clients or on the server.

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

[Keith]

THANK YOU all very much for these answers.

I suppose they are obvious, but I searched and did not find any clear
answers as given above

Keith

[Tony Toews [MVP]]

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

>No, not C:\Users. That's more for user data.

Huh? All the MS documentation I can find says that C:\Users is the
equivalent of C:\Documents and Settings as the location for user
profiles.

You may be right about that. I've gotta do more research on that one when I have
moment. I've been trying to get the Auto FE Updater working on 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/