It seems like we've all done this a hundred times before.  I know I have.  What I really want is a strongly typed argument object passed in from the command line, but all we get is a bunch of strings to parse through.  Yuck, I hate parsing strings.

There are a few existing command line parsing libraries in .NET.  I thought about using one of them, but I either ran into licensing issues, old .NET 1.1 code, or the library was just too big and over complicated for what I wanted.

Needing this functionality yet again, I decided to create a re-usable library that allows me to create my command line arguments via property attributes.  To create a new argument class I just apply a SwitchAttribute to each property I want settable from the command line.

    public class Options

    {

        private int port;

        [Switch("Port", "Sets the IP Address port of the server.")]

        public string Port

        {

            get { return port; }

            set { port = value; }

        }

    }

Then to use this options class from my console application, I only need to:

    private static int Main(string[] args)

    {

        CommandLineParser parser = new CommandLineParser(args);

        Options options = parser.BuildOptions(new Options());

        if (options.Port != 0)

        {

            // ...

        }

    }

As you can see, this is nothing fancy, but it makes building new console apps a little easier, and more importantly it makes adding or changing command line arguments much more maintainable since I only need to modify a single property forgoing any string parsing.  I can also get a nicely formatted list of what command line arguments are available along with their descriptions.

    foreach (string line in CommandLineParser.GetUsageLines(new Options()))

        System.Console.WriteLine(line);

Outputs:

/Port    Sets the IP sddress port of the server.

/Server   Sets the name of IP address of the server.

...

If you interested in using the library, its available in my Google code SVN repository under the Apache 2.0 license.

I was using ReSharper's Unit Test Runner today, and all was good until it suddenly stopped working with no error message.  You would run the tests, it would spin for a second, then show no results - everything was grey.  Try to run test in debug mode, same thing, no break points ever get hit.

This was very frustrating since I had no indication of what the problem was.  I ended up throwing the test DLL into NUnit itself, which showed a nice error dialog "Assembly Not Loaded" which indicated there was an error in the test project's app.config.  Argh!

At least it gave me an excuse to download and install NUnit 2.4.7.  Apparently they added rowtest support?  I like the sound of that.

You might immediately suspect a C# class is breaking the single responsibility principle when you discover upon opening it that the entire first page is nothing but using statements.  38 in all, and that's after using Re# to remove the unused ones.

Can you guess what kind of class this is?

If you guessed a code behind to a winform dialog then you guessed right.

I haven't been doing a lot of blog posting or work on my own personal projects this past couple of weeks because I've been spending my time reading.  I read the majority of WCF Programming, and have almost finished Release It.

Programming WCF Services is pretty much what you would expect from a book with this kind of title.  Lots of code examples of WCF.  Pretty dry and boring, but still the book goes into more depth than a lot of books on the topic.  The plethora of code is also very handy as a reference guide.  Overall I would recommend the book if you intend on doing any in depth WCF programming.  I do wish the book would have covered how to build better services: service contracts, data contracts, faults.  I suppose those topics are more general than WCF. My rating: 4 out of 5 stars.

Release It!: Design and Deploy Production Ready Software is the best book I've read in a long time.  There's only a couple lines of code in the entire book, yet the book provides excellent insight into design and architecture decisions for building and running robust, scalable, enterprise software.  If there's one take-away from this book, its design your systems to be loosely coupled, don't let a failure in a downstream service or application force your application to fail - build your software to be cynical.

Use timeouts!  Make services asynchronous.  Pay special attention to external integration points: services, networks, databases. Apply circuit breakers at external integration points.  Manage your resources wisely: bandwidth, CPU, and RAM are only so cheap, especially for large enterprise applications in a large farm.  Pay attention to your software once it goes live, don't throw it over the wall to IT. 

Build in monitoring and logging from the beginning, this could mean the difference between 10 minutes of down time and a days worth of down time.  Make your logging messages clear, so that IT can understand them.  Your customer facing software is your company, if your software performs poorly or malfunctions, it reflects poorly on your company, which ultimately shows up as lost revenue.

Again, Release It is an excellent book.  Go get a copy!  My rating: 5 out of 5 stars.

Unfortunately I've read the entire book in less than a week, and here I am without a book to replace it with.  My company was nice enough to give me an Amazon gift certificate, just for doing my job, so I decided to stock up so I wouldn't be without a book again, for a little while anyway.  I just ordered what I would consider to be "the essentials", since they are so often referred to:

• Patterns of Enterprise Application Architecture
• Refactoring to Patterns
• Test Driven Development: By Example

I realized that in almost every project I work on I end up defining a small preconditions assertion library.  I got tired of doing that, so I created a very small argument preconditions library.  That's all this library does - preconditions, that way I can add this to any project without any other baggage to go along with it.

I wanted the precondition library to be readable and short.  This is what I came up with:

Throw.If(regexExpression).IsEmpty();

Throw.If(instance).IsNull();

I think it intention revealing and short to write (especially with intellisense) than traditional precondition checks.  Another nice thing is that is type safe/smart, so only string arguments get string related precondition checks - like IsEmpty().

I checked it into my SVN repository on Google code.

I hate it when I forgot to include subjects in my outgoing email, unfortunately Outlook lets you send email with no subjects without prompting you.  This blog post has some VBA code to add that functionality.  Just remember to change the double quotes to the normal non-italicized flavor.

From Jeff Palermo in the comment section of Hammet's blog post:

I'm, at this point, very concerned that the average Microsoft developer will use ASP.NET MVC not to improve their application design, but merely because it's the new thing. I can see it now: before there was 1000 lines of code in Page_Load. Now there is 1000 lines of code in the controller action.

I found myself doing this today with Rhino Mocks:

[TearDown]

public void TearDown()

{

    mocks.ReplayAll();  // ensure replay was called

    mocks.VerifyAll();

}

I have a few tests in my fixture that don't use mocks, so forcing those tests to have mocks.ReplayAll() in them is just extra noise.  As it turns out calling Replay multiple times is safe, so tests that use mocks of course have already called ReplayAll, but tests that don't use the mocks can forgo having to call ReplayAll() just to have the tear down method run without error.

In case you didn't know, calling VerifyAll in RhinoMocks will throw an exception if you have previously called Replay.