I spend a lot of time writing windows services. If I had to install every one I worked on locally, my box would be terribly tired and a mess to boot.

A friend showed me a trick for starting the service in a console window. Use this code in your Main. You may have to add the string[] args parameter.

static void Main(string[] args)
        {
	   //Start IOC Container Structuremap
           //http://structuremap.net/structuremap/
            _bootStrapper = new IocContainerBootstrapper();
            _bootStrapper.BootstrapStructureMap();

            //This configurator starts up log4net
            XmlConfigurator.Configure();

            Log.DebugFormat("The SweetService service bootstrapped '{0}':"
              , ObjectFactory.WhatDoIHave());

            //Add '/console' to start options > Command Line Arguments in
            //your project properties
	    //to get the service to start in console for debugging
            if (args.Length > 0 && args[0] == "/console")
            {
      Log.Debug("Starting this sweet service in Console mode for debugging");
               SweetService myService = new SweetService();
                myService.OnStart(args);
                Console.ReadKey();
            }
            else
            {
                ServiceBase[] servicesToRun = new ServiceBase[]
                  { new LabImportEngine() };
                Run(servicesToRun);
            }
        }

Put  ‘/console’ in your Start Options / Command line arguments in your visual studio project properties and set your project type to Console Application.

When you start the project now in a debugger, you will get a lovely console window with all your log4net output and you never had to install the service to work on it.

For this example, I am using log4net and I am using a colored console appender.  That makes the output in the console window great.

Enjoy,

Jim

Just got back from Iowa Code Camp 7, which was fantastic btw.
Had a funny moment sitting in Lee Brandt’s nHibernate demo where two of my co-workers and I all realized that we were doing some rocket surgery. We had just started refactoring a legacy codebase by adding integration tests and were manually rolling back the database changes with several lines of handwritten sql deletes… (sorry). Looking at Lee’s demo code, we saw him using a transaction for the rollbacks and I hung my head in shame.

Thank you Mr. Tim Squires for writing out this code sample for me:

using NUnit.Framework;
using System.Transactions;
namespace ProjectName.Tests.Integration
{
    [TestFixture]
    public class TestClass
    {
        private TransactionScope _transactionScope;
        [SetUp]
        public void SetUp()
        {
            _transactionScope = new TransactionScope(TransactionScopeOption.RequiresNew);
        }
        //...Test some stuff, insert records, update records, etc...
        [TearDown]
        public void TearDown()
        {
            _transactionScope.Dispose();
        }
    }
}

My current logging strategy for debugging

In a method, at a debug level, log at least the values of each parameter you are passing in. For Example:

With a method defined like this:

public int DoThisThing(int firstNumber, int secondNumber)

My log4net statement might look like this:

Log.InfoFormat(“MyClass just ran DoThisThingwith firstNumber’{0}’ and secondNumber’{1}’”, firstNumber, secondNumber);

I find myself using this as a persistent debugging tool. It can be really handy to read back through the logs.

I generally use the Colored Console Appender if I am watching live.

If you haven’t used them, the technologies I am talking about are:

log4net

BareTail (for watching multiple logs or reading old logs)