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)      Comments [0]  .Net | C#

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)      Comments [0]  .Net | C#

Take a look at this little announcement that came out of OSCON last week...

http://port25.technet.com/archive/2008/07/25/oscon2008.aspx

Amazingly, Microsoft has agreed to join the Apache Software Foundation as a platinum sponsor.  Oh, in case you weren't aware, Microsoft has this little product called "IIS" that kind of directly competes against the open-source Apache web server.

Paradoxically, IIS would die to get the market share enjoyed by Apache, yet is neither free as in beer nor as in speech.  A fact that I imagine probably makes for a tough sell for the Microsoft marketing department.

The cynics are saying this is a bold move by Microsoft to help ease the sting caused by the PR fiasco known as "Windows Vista."

"Hey, look at us, you might think we suck and are inherently evil, but suddenly we love open source (well, not anything that is GPL'ed - but I guess that's just common sense)." 

I honestly don't know what to make of it.  I guess in the grand scheme of things, the $100,000 ponied up to join Apache can't even be considered a drop in the bucket for Microsoft.  As they said on TWiT this last weekend, "That just gets them on the mailing list."

Maybe it's like Sun-Tzu said (and later echoed by Michael Coreleone in Godfather II), "Keep your friends close, but your enemies even closer."

Tuesday, July 29, 2008 10:01:31 PM (Eastern Standard Time, UTC-05:00)      Comments [1]  .Net | Apache | IIS | Open Source

The first(?) meeting of the Atlanta alt.net user group is going to take place this Wednesday at the Thinking Man's Tavern in Decatur (which is conveniently located fairly close to my house).  I have already RSVP''d.  If you want to come, sign up soon.  The web signup page says there are only 2 spots left.  Hope to see you there!

Sunday, July 20, 2008 7:07:43 AM (Eastern Standard Time, UTC-05:00)      Comments [1]  .Net | alt.net

I ran into a piece of code today similar to this:

public class Base
{
    public Base()
    {
        this.Initialize();
    }

    protected virtual void Initialize()
    {
        Debug.WriteLine("Base.Initialize()");
    }
}

public class Derived : Base
{
    public Derived() : base() {}

    protected override void Initialize()
    {
        base.Initialize();
    }
}

public class FurtherDerived : Derived
{
    public FurtherDerived() : base() {}

    protected override void Initialize()
    {
        Debug.WriteLine("FurtherDerived.Initialize()");
    }
}

public class Tester
{
    public static void Main(string[] args)
    {
        Base myBase = new Base();

        Derived myDerived = new Derived();

        FurtherDerived myFurtherDerived = new FurtherDerived();

        Console.ReadLine();
    }
}

See any problems here?  Even though the compiler lets you call virtual methods from a base constructor, it's generally a "bad idea".  That's because the constructor in the derived classes defers its construction up to its base classes before it executes its own constructor (even if we don't explicitly call the base constructor like in the example).  Yet the call to a virtual function in the base class constructor is executed in the derived class implementation.  This can cause subtle, unexpected problems.

In the example above, things "happen" to go well.  It actually runs just fine.  It outputs the following as you'd probably expect:

Base.Initialize()
Base.Initialize()
FurtherDerived.Initialize()

But that's only because we didn't do anything significant in the derived constructors.  What happens if we change the FurtherDerived class:

public class FurtherDerived : Derived
{
    StringBuilder _sb;

    public FurtherDerived() : base()
    {
        _sb = new StringBuilder();
    }

    protected override void Initialize()
    {
       _sb.Append("FurtherDerived.Initialize()");
       Debug.WriteLine(_sb.ToString());
    }
}

Guess what happens when we run this code? FAIL!!! The dreaded, "Object reference not set to a reference of an object". Since the Initialize() method in the FurtherDerived class is called from the Base constructor, we are trying to access the _sb class level parameter before it's ever initialized.  We are calling a method on an class we know has not been fully constructed.  That ain't good.

The lesson is - never call a virtual method from a constructor.  At best, you are introducing a bug waiting to happen.  At worst, you've already done so.

Friday, July 18, 2008 11:57:17 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  .Net | Back To Basics | C#

A while ago, I wrote a post about using LINQ in C# to generate a random confirmation number.  On my current gig we are using Groovy to write test scripts for SOAP UI acceptance test cases (incidentally, SOAP UI is a great web service testing tool that probably deserves its own blog post). 

In order to generate a dummy random string, I used an algorithm similar to the one I used in the LINQ post and wanted to show how it would be implemented in Groovy.

// create the list of available characters
def availChars = []
('A'..'Z').each { availChars << it.toString() }
// even it out to about the same odds of getting a char or a number
3.times { (0..9).each { availChars << it.toString() } }

def generateRandomString = { length -> 
  def max = availChars.size    
  def rnd = new Random()
  def sb = new StringBuilder()
  length.times { sb.append(availChars[rnd.nextInt(max)]) }
  sb.toString()
} 

// print it out 10 times to see the randomness
10.times { println generateRandomString(8) }

If you're not familiar with Groovy, the -> symbol in the generateRandomString declaration marks a closure that takes one argument. In this case, it takes the desired length of the returned string. The last line invokes the closure n times. I really like (similar to Ruby) how you can pass function blocks as iterators over collections.  It makes creating a loop both simple and intuitive (e.g. 10.times).  And the syntantical sugar of creating a ranged list (e.g. 'A'..'Z') is another nice feature of the language.

Monday, July 14, 2008 2:21:50 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Groovy