Advertisment

Isolated Storage in .NET 

author-image
CIOL Bureau
Updated On
New Update

By: Sujay Verma

Advertisment

As applications grow in size and complexity, they need storage space to put their settings and other data. In Windows, it used to be stored in flat text files initially and later in programmable and portable INI files. Then came the all-purpose Windows Registry. Some cross-platform or large applications today, even use RDBMS to store such information. Whatever method is used for storing such data, it must have certain characteristics.

For one, it should be secure. One user must not be able to look up another user's data or profile. Secondly, this profile should be roaming. If user X logs in from machine A today and from machine B tomorrow, the same profile/settings must be accessible from both the machines. Windows Registry and file-based profiles come woefully short here. Oh, you say, you can always store the information on the server! But what about applications that do not 'run' on a server? For example, applications deployed through the .NET ClickOnce deployment-these are downloaded to the user's PC and run from there. This is where IsolatedStorage comes in handy. It is nothing new. It has existed since .NET release 1.0. Here is how you get your applications to use it.

Direct

Hit!

Applies to: Intermediate/Advanced .NET developers

USP: Use the concepts outlined to create roaming profiles and store information on a per-credential basis.

Primary Link:

http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemioisolatedstorage.asp
 

Google keywords: : isolatedstorage
On PCQEssential CD:

Developers_Lab\IsolatedStorageDemo.zip
Advertisment

Our sample application is loosely based on the example on the MSDN website. But we get it to do things a little differently and even add a WinForms GUI. What we shall do is expose a Windows Explorer style tree/content view on a WinForm, where we display all the files and folders for a particular user. In our application, you cannot create new folders and are limited to just the 'IsolatedStorageDemo' folder. But it is a 'limitation' you can bypass very simply by adding about two lines of code. We do not enforce a technical 'login', but we need the name of a user and we get it using a simple name-only box in our startup screen.

UserProfile class



We have encapsulated the elements of the .NET IsolatedStorage class within the UserProfile class in this project. While IsolatedStorage allows us to do everything a normal file-system does, such as enumerate and traverse directories, read and write files, delete and copy data and more, our class allows the program to read and write files. All files are created within the 'IsolatedStorageDemo' folder-you can create a different folder if you want. The contents of the class can be simply summarized as follows.

Imports System.IO



Imports System.IO.IsolatedStorage


Imports System.Security.Policy

Advertisment

Public Class UserProfile



...


Public Sub OpenStore()


...


End Sub





Public Function GetFolders(...) As String()


...


End Function





Public Function GetFiles(...) As String()


...


End Function





Public Function AddFile(...) As Boolean


...


End Function





Public Function GetFile (...) As String


...


End Function





Public Function DeleteFile(...) As Boolean


...


End Function


End Class























The OpenStore function initializes the IsolatedStorage container for our application. We OR scope it with three flags-User, Assembly and Domain-letting it open files created under any of these scopes. You will notice that if you remove one of these flags an exception is thrown, because of security policies that disallow an application opening storage resources from other scopes. User scope applies to the logon-user, assembly is your .NET app and Domain is the logon domain (if in Active Directory) or local system. Although you can do all file operations to files within the isolated storage container, you cannot get handles to such files, like you can with normal IOstream operations. This becomes evident if you try to fetch the value of the Handle property for our IsolatedStorageFile object. Therefore, all read/write operations on files are performed using the IsolatedStorageFileStream class, as in lines 54 and 79 of the UserProfile.vb file. The data is stored as bytes (converted to bytes in line 48) and needs to be read and converted to a string (lines 86-89).

The file system



The storage container replicates a regular file system. To get at them, we have the GetDirectoryNames and GetFileNames functions that return string arrays. They also accept a parameter, which has to be a '*' to get all entries. However, they only get it for one level. For example, our 'IsolatedStorageDemo' folder lies within the root folder in the container and a file 'File1' will be created in this folder. But to access File1, you will need to pass 'IsolatedStorageDemo\*' to the GetFileNames function. This is the reason for the nested For-loops in lines 179-193 of frmIsoStore.vb (the form). You can use the commented line in line 186 to clear all these files if required, that is, you cannot get rid of them with a wildcard as in

System.IO.

Advertisment

Running the program



Load the solution in VS.NET 2003 and run it. A login screen will appear. Enter any name following the 'login name' syntax from Windows and click on Login-such a login does not need to exist for our application. The second explorer window will open, showing the folders and files on the left-pane. For the first run, this pane will be blank. Enter the name of the file in the upper textbox and enter some text in the lower (larger) box. Click on Save. The file will be saved and the treeview will refresh with the new file. Create a couple of files. To see each one, simply click on the node (you will need to click three times on a node, because of the treeview control's property) and the name and content will appear on the boxes to the right. Click on Delete if you want to delete a file-the views will refresh again.

Possibilities



You can now reuse the code almost as it is from UserProfile.vb to store persistent information from your applications. The best part is, the same thing also works for your ASP.NET, Windows Service and other .NET application types.

Source: PCQuest

tech-news