How to decide where to store per-user state? Registry? AppData? Isolated Storage?
Asked Answered
H

4

23

When should the Windows Registry be used for per-user state, and when should we use the filesystem, particularly the user's AppData folder? (eg, C:\Users\USERNAME\AppData). Where does Isolated Storage come in?

Is there a pretty firm rule, or is it just a fuzzy thing, like "use the registry until it becomes too much data to store in the registry". or "use whatever you feel like using."

Are there Windows logo requirements that affect the decision?

If I use the AppData directory, how do I choose between Local, Roaming and LocalLow ?

edit: I just noticed these similar questions:

I will summarize replies.

Hypoplasia answered 19/5, 2009 at 12:36 Comment(0)
D
14

If you have a small number of key/value pairs and the values aren't big the registry is great - and you don't care about xcopy deployment - then use the registry (I know this isn't exact, but it's usually obvious when working with the registry becomes a pain).

If you want xcopy deployment the data must be in the same folder as the program obviously - but the program can be somewhere under the AppData folder, it doesn't have to be under "program files".

Use isolated storage only when you need it or have to use it - for example ClickOnce.

Otherwise use AppData\Roaming, use Local or LocalLow only if you have a good reason.

EDIT: Here is the difference between Roaming, Local and LocalLow:

Windows has a little known feature called "roaming profiles", the general idea is that in a corporate environment with this feature enabled any user can use any computer.

When a user logs in his private settings are downloaded from the server and when he logs out his settings are uploaded back to the server (the actual process is more complicated, obviously).

Files in the User's "Roaming" folder in Vista or "Application Data" in XP move around with the user - so any settings and data should be stored there.

Files under "Local" and "LocalLow" in vista and "Local Settings" in XP do not, so it's a good place for temp files, things that are tied to the specific computer or data that can be recalculated.

In Vista, as part of the new security features we all know and love, you can have programs running in "low integrity mode" (for example IE in protected mode), those programs are running with reduced privileges and can't access files in the user's profile - except for files under the "LocalLow" folder.

So, in conclusion, files stored in "LocalLow" are inherently insecure and files in "Local"/"Local Settings" are likely to be unavailable in some large companies - so unless you have good reason and know exactly what you are doing go with "Roaming"/"Application Data".

Durrace answered 19/5, 2009 at 14:34 Comment(4)
Could you elaborate on AppData\Roaming vs. Local - why is it better?Ratiocination
Sergey, I've added the information you requested, I hope you find it usefulDurrace
%APPDATA% points to the Roaming folder. Is there one that points to the local folder? (Other than %APPDATA%\..\local)Najera
@Najera - %LOCALAPPDATA% (at least on windows 7), you can see all the defined environment variables by opening a cmd window and typing "set" (with no parameters)Durrace
K
7

Don't clutter up my Registry thank you.

Use isolated storage, thats what it's for.

See Was The Windows Registry a Good Idea? On Jeffs Blog...

Karaganda answered 19/5, 2009 at 15:43 Comment(0)
A
4

You might want to consider Isolated Storage.

Altazimuth answered 19/5, 2009 at 12:37 Comment(1)
ok, Thanks. Good information. Isolated Storage uses a subdir within AppData for the actual location. It is also nicely isolated. So I guess it comes down to a size-based decision. If it would require more than a few reg entries, then use isolated storage?Hypoplasia
Q
1

I don't know whether there is a firm rule, but but one thing to consider is that the registry is transacted -- it is safer for concurrent read/write operations. So, if your user data might be written by multiple threads at run time (or if you have multiple exe's in your product package), consider using the registry.

History: One reason (as I heard it) that MS went from .ini files to the registry was precisely to try to handle the concurrent access problem.

.Net (sort of) went back to .ini files in the form of xml .config files, however those config files are not supposed to be written to at runtime (or at least not if there is a chance of concurrent writers/readers).

More info: http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx

Quadric answered 19/5, 2009 at 13:55 Comment(1)
the user config file is designed to be modified at runtime.Assam

© 2022 - 2024 — McMap. All rights reserved.