Isolated Storage
In my last post, I showed how to write stuff out to a temporary directory. After I wrote the post, I started thinking about how people could misconstrue the meaning of it. The post was intended to show how to dump stuff easily to a random directory on the file system. The code that drove me to write that particular example came from a unit test that was using the temporary directory as a repository for the output of the XmlSerializer. In other words, I really was not doing anything meaningful with the data.
To clear things up, I thought I would write a post that showed how use a unknown storage directory as a meaningful repository for application data. What constitutes meaningful data? I don't know, it's your app!!! But common possibilities include application settings, user-specific data, etc... I'm thinking of things that might be otherwise be stored in the registry. Yeah, don't do that anymore. I don't know about you, but the just the word "registry" causes me to shudder.
.Net has introduced a new concept called "Isolated Storage" to hold this type of information. Isolated storage is an unspecified location on the file system that is hidden away from the application. Even though the location is unknown, the application is guaranteed to have full permissions to it, even if it is running in a restricted security mode. As it name implies, the location is "isolated" so that any data written to it does not affect other applications or anything else on the file system. So as far as security goes, you're limited to only hurting yourself by maliciously or ignorantly (mis)using this repository.
Here's a code sample of how you would use it to store data:
// get the location specific to this user/assembly
IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForAssembly();
// create a file to write the data to
using ( var outStream = new IsolatedStorageFileStream("foo.txt", FileMode.Create, isf) )
{
using ( var sw = new StreamWriter(outStream) )
{
// write out the text
sw.Write("Random text");
sw.Close();
}
}
And here is how you can retrieve it:
IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForAssembly();
// open the file
using ( var inStream = new IsolatedStorageFileStream("foo.txt", FileMode.Open, isf) )
{
string[] files = isf.GetFileNames("foo.txt");
if ( files.length > 0 )
{
StringBuilder sb = new StringBuilder();
foreach ( var file in files )
{
using ( var sr = new StreamReader(inStream) )
{
sb.AppendLine(sr.ReadLine());
}
}
}
}
This method is a much more "enterprise-y" way to access data in your applications.
Saturday, August 09, 2008 3:45:26 PM (Eastern Standard Time, UTC-05:00) 
.Net | C#
Using Temp directories in .Net
Have you ever found the need to use a temporary directory on the file system in your code? This issue came up with me recently (and bit me in the ass), so I thought I would share some experiences on how I overcame the problem.
At the root of the problem is that you need some sort of permanent storage, but nothing that is stringent enough to require it reside in some "known" directory where it can be accessed at a later time. You don't really care where you store a file, but you need to store it somewhere.
I recently came across a piece of code in a unit test that serialized a class using the XmlSerializer. The person who wrote the test must have wanted to see what the class looked like in serialized form. The code was written so that the xml version of the class was dumped to the file system. However, when the test was written, the file was hard-coded to the C:\Temp directory.
As part of my task, I was incorporating the unit tests on this component into the continuous build. Guess what happened when the test was moved the build server? FAIL!!! No C:\Temp directory on that machine means lots of red on the build server and the IT director screaming WTF?!?!?
The lesson is, never make assumptions when accessing the file system. In this case, the test was counting on the directory both existing and the user having permissions to it. Obviously, that's not a good idea.
There are other ways to get to a valid "temporary" directory in .Net. The following code sample shows how you can try a few known places in .Net that should work as "temporary" directories.
/// <summary>
/// Get a valid "temporary" directory on the machine that is running this code
/// </summary>
/// <returns>a temporary directory</returns>
private string GetTemporaryDirectory()
{
// try this first
string dir = Path.GetTempPath();
if ( String.IsNullOrEmpty(dir) || !Directory.Exists(dir) )
{
// see if the "TEMP" environment variable is set
dir = Environment.GetEnvironmentVariable("TEMP");
if ( String.IsNullOrEmpty(dir) || !Directory.Exists(dir) )
{
// hmmm ... let's create one in "My Documents"
string myDocsDir = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
if ( String.IsNullOrEmpty(myDocsDir) || !Directory.Exists(myDocsDir) )
{
// no "My Documents" directory???
throw new Exception(
"Cannot determine a valid temporary directory on this system. " +
"Please set a valid directory for the \"TEMP\" environment variable.");
}
dir = String.Format("{0}\\Temp", myDocsDir);
if ( !Directory.Exists(dir) )
{
Log.Info("Creating new Temp directory in {0}", myDocsDir);
Directory.CreateDirectory(dir);
}
}
}
if ( dir.EndsWith("\\") )
{
// cut the last char off
dir = dir.Substring(0, dir.Length - 1);
}
return dir;
}
The code example above tries to use the .Net libraries to query the file system for some well-known directories that can be used for temporary files. If a valid one is not found, it will try to create a "Temp" directory in the current user's "My Documents" directory. At worst, the user should have access to this directory, and the build should not break based on a hard-coded assumption.
Friday, August 08, 2008 12:46:30 AM (Eastern Standard Time, UTC-05:00) .Net | C#