Rules for multi-user WinForms apps on Vista

Question

We have an MSI installer for a .Net WinForms app for Windows XP that installs and runs only as an admin. Users have to log in to the app when it runs. Customers want it to install and run under a user account under Vista, and to use their Windows account.

A preliminary look through the code shows lots of problems; the installer writes to the registry and installs the app in C:\Program Files. The app stores user preference in the registry, writes data to C:\Documents and Settings\All Users\, and creates temp files in C:.

I guess the first thing to do is store data files in System.Environment.CommonApplicationData and user preferences in System.Environment.LocalApplicationData. Can a user account install an app to System.Environment.ProgramFiles?

A problem is that the app must be installable and uninstallable by any user, and all users share the same data files. Each user has their own preferences.

Is there a book or web site that gives a detailed breakdown on what is required to build a WinForms app that obeys the rules for multiple users on Vista?

Edit: I checked with the client and the requirement to install only as a user account is firm, they are removing admin access from floor staff. This rules out admin-installed components and per-machine installs.

I was thinking of creating a separate data app that would run on an admin machine which the floor machines would connect to via remoting. All client data would be stored on this machine. However, this app would also have to install and run under a user account.

Is there a book or site describing all the rules which Vista user apps must follow?

Answer 1

"the app must be installable and uninstallable by any user" "all users share the same data files"

You're going to have trouble with having to meet both of these requirements. Vista's new security features are designed to keep users from trampling on each other (and on the system).

About the only way I can think of to make this work is a way similar to how we handled a requirement like that on a Windows 2000 environment. You build two components -- the user part of the app, and a system component that manages the information that's shared between the users. An admin installs the 'shared' component (which includes a windows service to run it), and each user installs the 'user' component.

I think that might work for your scenario, but it would require re-working your code that uses the shared files to talk to the service instead of accessing those files directly.

Of course, you could also just have a tool the user runs as an admin to create your folder in a specific place and grant the needed security permissions. That might work for your purposes as well.

Answer 2

You will have problems allowing the application to be installed by any user, and at the same time access shared data files. This is because your first requirement implies a per-user install, whereas the second implies a per-machine install. Let me explain ...

Standard (MSI-based) installers can be scoped to be either per-user or per-machine:

• Per-user installs put the installed program files somewhere under the user's home directory. The application is installed for that user only. Other users don't even see the program in the start menu nor Add/Remove Programs. If they want the program, they have to install it themselves into their own per-user area. So there may be multiple copies of the program installed, and each one is isolated from the others. This type of installation can be performed by regular (non-admin) users, which is why they can't write to shared areas such as "Program Files" or "All Users".
• Per-machine installs can modify shared areas of the file system (ie "Program Files" or "All Users"). Each user sees the same copy of the program in the start menu and Add/Remove Programs. Only admin users can performs this type of installation.

Answer 3

Thanks guys. I checked with the client and the requirement to install only as a user account is firm, they are removing admin access from floor staff. This rules out admin-installed components and per-machine installs.

Our solution was to create a new Standard User account for our app. Staff who need to use the app must log on as this user. This actually turned out better than sharing data between users because now we can host the app for different clients on the same machine.

I also found a great reference for making multi-user apps on Windows, the Microsoft Windows 7 Client Software Logo Technical Requirements document.