Month: June 2009

I just saw a blog post from Bill Sempf describing a book he'd written for Microsoft to help them explain licensing for Windows Server 2008.  At first, I read right past a key metric, but I doubled back and read it again -- the book is 86 pages long.

Eighty-Six pages?? Really???

Now, don't get me wrong.  I have every faith that Bill's done a fine job of documenting the licensing requirements in the simplest fashion possible.  I don't mean to bash the book; I mean to bash the licensing requirements.

Do you think there's a chance that the real problem here isn't the fact that nobody liked reading licensing whitepapers?  Maybe the real problem is that the licensing model takes 86 pages to explain in a "Dummies" book.  How long is the "Licensing Unleashed" book going to be??

I'm not exactly sure how you fill up 86 pages with licensing guidelines, but I have to guess you're going to see chapters like this:

• What's it going to take to put you in a new OS today?
• If you have to ask, you can't afford it.
• Feeding Ballmer's Ellison-envy since 1998.
• If you think the licensing rules are complicated, you should see our commission calculations.
• This is going to hurt me more than it hurts you.
• Hang on a second while I go talk to our General Manager.
• How much did you say your budget was again?

Enjoy the read, though.

Logging is one of those "system" components that always seems to either be left out or way over-engineered (glares at Microsoft's Enterprise Application Blocks). Today, I'd like to introduce you to a logging framework that's everything it needs to be and nothing it doesn't.

The .Net Logging Framework from The Object Guy is powerful enough to handle any of your logging needs, but simple and painless to use.  Here's a relatively complicated example -- we're going to log to three logging sources to demonstrate how easy it is to set up.  In most cases, of course, you'll log to only one or two sources:

/* first instantiate some basic loggers */
Logger consoleLogger = TextWriterLogger.NewConsoleLogger();
Logger fileLogger = new FileLogger("unit_test_results.log");
Logger socketLogger = new SerialSocketLogger("localhost", 12345);

/* now instantiate a CompositeLogger */
logger = new CompositeLogger();

/* add the basic loggers to the CompositeLogger */
logger.AddLogger("console", consoleLogger);
logger.AddLogger("file", fileLogger);
logger.AddLogger("socket", socketLogger);

/* now all logs to logger will automatically be sent
to the contained loggers as well */

/* logging is a one-liner */
logger.LogDebug("Logging initialized.");

When you download this logger, you'll get all the source code, including a socket reader to catch the logs thrown by the socketLogger in the example above.  Extending the logger is a piece of cake, too, so you could build yourself a WCF Logger, for instance, in no time flat.

You'll note the lack of config file-driven settings in the example above -- this is purely intentional.  You can decide if you want to make any of these settings configurable, and do so in the format you're comfortable with, so you don't need to try to get your config files to conform to whatever format your logger insists on using.  This small simplification can be a big time-saver for simple apps, debugging / test harness apps, and so on.

Introduction

There's no question that Visual Studio is a class-leading tool for building large applications.  The IDE is incredibly helpful to coders, and the .Net framework lends itself to managing dependencies among components and classes in large applications.  In addition, Visual Studio is designed to be extended by third-party tools that can make it even better.  NDepend is one of these tools; its purpose is to analyze large applications and expose information that's typically hidden deep inside your code.

Installation and getting started

The NDepend web site shows some great screen shots with all manner of graphs and charts and reports, so naturally, you want to see that stuff for your code, too, right?  Good news: installation is a piece of cake.  Just unzip into a directory, add the license file, and you're ready to start your first analysis.

When you start the NDepend Startup shows a screen reminiscent of Visual Studio (start screen).  Create a new project, point it at a Visual Studio solution file, and let NDepend do its thing.  Zero to more graphs than you can shake a stick at in about four minutes:

Continue reading "NDepend review"