By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,956 Members | 1,722 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,956 IT Pros & Developers. It's quick & easy.

Storing state data

P: n/a
I am looking for different opinions on how the state data of a .NET
application should be stored. An example would be the size and location of
the main application window. This allows the users' preferences to be
restored the next time the application is run.

The classic DOS/Windows method was to use a ".ini" file in the application
directory. This had the advantage of being very easy to backup and would be
deleted if the application were uninstalled by deletion of the parent
directory.

Along came Windows 95 and the advice from Microsoft was to store all
application settings in the registry. This has the disadvantage that the
settings are not removed by deleting the application. Even using a proper
uninstaller (e.g. InstallShield) will not remove all of these settings if
they were created at runtime instead of install time.

Now we have the NT/2000/XP line from Microsoft. This has built in file
security so we can no longer store a ".ini" file in the application
directory because the current user might not have write access to the
Program Files directory. Microsoft have kindly provided us with a special
directory for this purpose at some memorable location such as:
"C:\Documents and Settings\UserID\Application Data\Tessella\AppName"
This has the same disadvantages as the registry in that most users will not
know it exists and if the file is created or modified during runtime, the
uninstall program will not remove it.

We now have the claim that a .NET application can be installed with a
simple copy operation such as xcopy and that all of our settings should be
stored in an XML file. Where should we place this XML file? We cannot place
it in the application directory because the user might not have write
access to it. Last time I checked, xcopy was unable to dynamically obtain
the Application Data directory.

Do you use XML files with your .NET applications or do you still use the
registry?

How do other operating systems or development platforms deal with this?

Microsoft has recently released "Microsoft Application Blocks for .NET"
which seems to solve all of these problems. See:
http://msdn.microsoft.com/library/en.../html/cmab.asp
This gives me confidence I'm not the only one having this problem. Has
anyone used this?
Jul 21 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.