Debugging a Windows Service Startup Method

It’s been a long time since I wrote a Windows service but…I was doing that today and realized that the more things change, the more they stay the same. It would seem that it’s still a painful and problematic process if you want to debug the startup of a custom Windows service you write in Visual Studio.  If you follow the published guidance around this (, it suggests a variety of work-arounds for doing this, but nothing that I would call an out of the box solution.

Well…there IS an out of the box solution.  So even though it may not be rocket science I guess it’s worth sharing.  If you want to break in on the OnStart event of your custom Windows service, just add this line in your code where you want to start debugging:  Debugger.Launch();

Compile your code then install the Windows service.  When you start the service you should see a dialog that asks you if you want to debug the service – like this:

Just say yes and another dialog will pop up where it asks you if you want to start a new instance of Visual Studio, or use an existing instance.  Of course you will have Visual Studio already up and going with your source code for your service loaded and break points set.  Just pick that instance of Visual Studio and – voila’ – you are debugging OnStart.  Old school sometimes works best.  🙂

Using PowerShell for SharePoint 2010 in C#

A buddy of mine at Microsoft was good enough to point me to this video on channel 9 that talks about using PowerShell from your C# code without doing the dreaded process and spawn routine we’ve probably all used before.  To begin with, watch the 4 minute video at  Once you get the basic steps there for adding the appropriate references to your code and using statements to your class, there are a few other useful things to know as it relates to SharePoint 2010 and PowerShell:

  • Start with the standard process to create your PowerShell process:  PowerShell ps = PowerShell.Create();
  • Add the SharePoint snap-in like this:  ps.AddScript(“Add-PsSnapin Microsoft.SharePoint.PowerShell”);
  • Now you can create your SharePoint PowerShell commands as strings and run them.  Here’s an example of adding a new data connection library to the list of trusted data connection libraries in Excel Services.  This is a good example of something that can only be done in PowerShell because there aren’t any adminstrative APIs for it, so it made a good test case for this methodology.  So here’s what it looks like to create the command: 



    string pCmd = “New-SPExcelDataConnectionLibrary “ + “-address ‘http://farm2/sites/sporeports/dcl’ “ + “-ExcelServiceApplication ‘Excel Services Application’ “;

  • And now add it to the list of cmdlets to run: ps.AddScript(pCmd);

  • Finally, to execute your PowerShell script:  ps.Invoke<string>();

Overall this is a pretty nice way to tackle scenarios when you have managed code but need to fallback to PowerShell for getting a task done.  When you get into it there are some other interesting ways you can tackle using cmdlets, using the CmdletInfo, CommandMetadata and ProxyCommand classes.  Unfortunately they still break down when you are working with non-public APIs but the basic approach I described above continues to work well in those cases too.