This tip, excerpted from InformIT, discusses isolated storage and in which circumstances you should use it.
The question of where to store user-specific application settings has plagued developers since the dawn of the PC. Prior to Windows 3.1, applications typically stored settings in a configuration file in the application directory. Windows 3.1 introduced the concept of initialization (.INI) files, and their associated headaches--corruption of WIN.INI, INI droppings all over the Windows directory, and inadvertent corruption or deletion of other applications' INI files. The Win32 platform introduced the registry -- a system-wide configuration database in which developers were encouraged to store application settings. However, it's a bad idea to store large amounts of data in the registry, and giving just anybody write access to the registry poses a serious security risk. The registry is a fine place to store application configuration data that system administrators control, but it's not a good place for user-specific application settings. In .NET programs, those settings belong in isolated storage.
What is isolated storage?
According to the .NET definition, "Isolated storage is a storage mechanism that provides isolation and safety by defining standardized ways of associating code with saved data." The isolated storage subsystem standardizes access methods, provides security by preventing other programs and users from accessing application-specific data, and supplies tools that help system administrators configure and control the storage space. Isolated storage provides a standard, flexible, and (to an extent) secure location for an application to store its settings -- a place where other applications can't inadvertently overwrite or delete.
How isolated is it?
Access to an isolated storage fi
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
le is always restricted to the user who created the file. This setup prevents users from inadvertently overwriting or deleting application settings that were created by other users or programs. The .NET runtime uses the operating system user-identity mechanism to support this isolation. In addition to user isolation, storage can be isolated based on the assembly (a DLL that contains all kinds of .NET-specific stuff), or on the combined application domain and assembly. () By combining user, domain, and assembly, the .NET Framework provides these two types of storage isolation:
Isolation by user and assembly. Data isolated by user and assembly can be accessed only by the user who originally created it, and only from code that resides in a particular assembly. This type of isolation is useful if you have multiple applications that need to access the same configuration data for a particular user. If you create a separate assembly that accesses the isolated storage, any application that calls the assembly can access the data for that user.
Isolation by user, domain, and assembly. Isolation by user, domain, and assembly is more restrictive. In addition to restricting access based on user and assembly, the runtime ensures that the only application that can access the data is the application that originally created it. This type of isolation prevents data leakage between applications, as well as data corruption by other applications.
When to use isolated storage
With the few exceptions noted below, you should use isolated storage anytime you need to store user-specific application settings. These situations cover a wide range of possibilities:
To read the entire article from which this tip comes, click over to InformIT. No registration required. No hassle, no problems. Just good information.
