The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Installer Best Practices

I'm noticing that there are a lot of issues reading/writing files to the "Program Files" folder in Vista.
A lot of security issues, etc., that can be problematic for users.

It seems like if you are going to create a Director Projector, and have a lot of file writing going on (in my case via the Arca Database), you should have users install your software in a folder on their "c:\" drive directly, as opposed to installing it on a folder in the "c:\Program Files\" folder.

Is there any good reason NOT to do this, other than it being more common practice to have it be installed in the "Program Files" folder?

Thanks for ANY insights you can give me!!!
Randy Send private email
Sunday, April 13, 2008
Windows is a multi-user operating system. You put the shared stuff in Program Files (the exe's and dll's), and write per-user data into the user's profile. If you want to write data accessable for all users, put it in the All Users profile.

There's standard places for all this stuff. Doing something different requires reinventing the wheel, and makes backups more annoying.
Chris Tavares Send private email
Sunday, April 13, 2008
I will once again point out that this is not a Vista issue. The same issue exists for limited users in XP and standard users in Win2000. Most programmers have simply been oblivious to it all these years. Chris has pointed out the standand practices that should have been followed all along.

The only reason I can see for installing the base application outside of the Program Files directory is if you want to support automatic program updates that can be performed by non-admins. There have been many discussions about this on the forum and the jury is still out on the technique that should be used. If you are not providing automatic updates then follow Chris' advice above. Programs go under Program Files and data goes under either the user's profile or the shared/common profile location.
dood mcdoogle
Sunday, April 13, 2008
I have just been through the same worrying procedures and despite what some people say, the real world is quite confusing.

At first I thought of using "standard" directories but to have a user send you a log file that has been placed into a 'hidden' folder is a nightmare - even if they have administrator privledges.

Installers in Vista will get automatically upgraded to administrator status so using your installer to install files won't cause a problem.

I ended up going with the following:

Use the All Users application directory to store the database as well as the log file. This directory is read/writable so the user can access it if they know how to 'unhide it'.

The Program Directory holds the program plus any files that only need to be read by the program. The user should never need to access the program directory. The program itself only ever reads from this directory.

A directory off the root directory to store the template files that are editable by the user and the program.

I use the installer to install files into the first two directories but I use my program to create and maintain the programs 'template' directory.

I found it easier to create a procedure in my program to archive the database and log files and place them into the users My Documents directory. The program then opens the users email program with a preformatted email that includes the details of the path to the archived file to send to me as an attachment.

I haven't had any negative feedback so I guess the above works and that's whats important I guess.
glen harvy Send private email
Sunday, April 13, 2008
I have maybe 100 programs installed. If each of them wanted to create a top-level folder then I would be very p***ed off.

Follow the Microsoft standards. Executables should be in "Program Files" and user data should be in their profile. Without this you are exposed to the following issues:
- A domain policy that restricts what folders are executable.
- Roaming profiles where the user can hot-desk and expect their data to move with them.

If your app crashes so many times that the support overhead of your users getting to the 'data' folder is too high then create a shortcut to the folder in your folder in the start menu.
Monday, April 14, 2008
Coming from an IT perspective, for the love of all that is holy and good, use the standard locations.  Nothing peeves me more than a bit of software that scatters itself all over the system, and then proceeds to break because some unrelated set of directory permissions got changed.
Don Werve Send private email
Monday, April 14, 2008
I would like to think that my users are tech savvy but they aren't. They are usually club secretaries that know nothing of computer intracacies, permissions etc.

I think anyone with support experience will appreciate what I say when you ask someone from the other side of the world to do something that their computer won't allow them to do. They often have great difficulty in describing their problem let alone navigating hidden directories.

I would ask someone that has practical experience to give me the 'corect' solution in the following scenario:

The admin user can install either for themselves or all users. This is selected by the admin user and handled by the installer. The program user needs read access to the log files so they can check/verify what has occured - not just for tech support issues (accounting and auditing). The program user needs read/write access to template files as does the program. The program user may or may not be an administrator.

The program user has no knowledge of privledges and believes that if they do a search for a file and it isn't shown then it doesn't exist. Even to the extent that they will vehmently tell you that it doesn't exist even after they said they strictly followed your instructions on how to find it!! You can include a log reading form and they can read it via that but they still insist it doesn't exist.

I have followed standards to the hilt (at least as far as I can tell) and have incorporated several 'features' into my program to make my support life easier but I still can't come up with a practical solution as to where I put the template files so that anyone (that means any user)can read/write to that directory.

In short - how's the common 'My Documents' folder referenced in the installer as well as my code and tell me why the location on the HD (but not the reference) has changed in Vista from XP. I just can't find how to create and reference a folder created in the so called Common Documents folder that is universal/standard.

Perhaps some guru can show me how to achieve the above so that I can keep to standards.
glen harvy Send private email
Monday, April 14, 2008
You don't need to.

Just make a copy of these templates into My Docs when your program is launched by an user - for his first time.

A common doc dir is bad because everyone may hack or delete others' files....
AqD Send private email
Monday, April 14, 2008
> In short - how's the common 'My Documents' folder referenced in the installer as well as my code

Use the SHGetSpecialFolderPath API function with the CSIDL_COMMON_DOCUMENTS constant. More info here:
Tuesday, April 15, 2008
If you are programming in .NET, use the System.Environment.SpecialFolders enumeration which just wraps the SHGetSpecialFolderPath API function mentioned above.
Tuesday, April 15, 2008
uggh - clearly you have never tried that option. If you have succeeded then please let me know which one returns the common_documents folder because none of them do on my machine. I thought about various workarounds but what if the common_documents is truely in a separate network share or similar.

Adrian - I am aware that such a CSIDL exists but as I only know C# I was to lazy to figure out how to implement it. A quick search on google only revealed a whole new class I need to implement just to get at one item.

I'm sure it's probably very easy to achieve - just a well hidden 'best practice' :-)
glen harvy Send private email
Tuesday, April 15, 2008
Did you know that if I add a file to c:\documents and settings\all users\documents directory it doesn't appear in the MyDocuments folder on W2K3.

So how do i use 'best practice' and not use a directory of the root drive for my globally editable templates?
glen harvy Send private email
Tuesday, April 15, 2008
I'd like to thank everyone for their input. This was my first time posting to this forum, and I never realized how helpful it and all of you are.

As for a conclusion, however, it appears as though this is what it looks like.
There obviously ARE best practices, and a way you SHOULD do it. But unfortunately Windows makes it so if you follow these standards, if anything you are going to cause more problems for your users than if you just DON'T follow them.

The risk reward seems like this:
If you create the installer on the root, it will be annoying for some users (and for the general "standards" following community.
But most of this is from an aesthetic standpoint. But that's about it.
For the most part, you are going to run into a lot less conflictions, problems, and ultimately-support issues!

Am I not right?
Wednesday, April 16, 2008
>> Am I not right? <<

You're completely wrong. But don't let that stop you.
Mark Pearce Send private email
Wednesday, April 16, 2008
One way to handle the problem might be to have an application setting for the template folder. That way, your users could even anoint a path on a network drive as the template folder allowing templates to be shared across more than even a single computer. You could store this value in the registry (which would require administrator access to change) or in a config file in All Users\Application Data.

Alternatively, you could add shortcuts to the various data locations to the start menu when you install - I'd imagine that most people could follow instructions like:
 1. Click on Start.
 2. Click on All Programs.
 3. Click on Wizmatic 2000.
 4. Click on Templates (or Logs).
Gareth Send private email
Monday, April 21, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz