Since my InfoPath 2007/InfoPath Forms Services project has ended you will start to see more posts on my blog about other SharePoint related things and less about InfoPath 2007/InfoPath Forms Services.  My new project is currently in NYC and it will last until March 31^st.  The project is a 100% different than my last project and I'm sure I'll be learning a lot of new things for this blog.  This post is from another project that I'm doing on the side and I just wanted to share a small piece of it with everyone.  If you're attending the South Florida Code Camp then you will get the full picture of everything if you attend my second session "Creating custom commands for STSADM with C#".  Later in February I'll also do a couple of posts on my blog to explain more of the details if you can't attend the code camp.

Ok, enough of my babbling and now to the details of the post.  A few weeks ago I needed to extend the STSADM utility to do a couple of things that it current doesn't have commands for or at least I couldn't find them.  When I built the initial project and deployed the assembly and started to test everything I ran into problems with the code (I wish I could write perfect code).  I struggled trying to get all the code working correctly without having the capability of debugging the code while it ran.  I could have done the old "Console.WriteLine" but I didn't want to go through this approach because I was tired and it would have been way too tedious for me.  This was really frustrating and I decided to figure out what needed to be done to make debugging an option.  I did a little searching but couldn't find anything that helped me (probably not using the correct search words).  When I started to really think about the whole scenario it reminded me about onetime I had to write a Windows Service and I ran into the same type of problem.  To solve that problem I added the "System.Diagnostics.Debugger.Launch" command to my code so I could debug my Windows Service.  So I figured what the heck and I added it to my code and everything complied without a problem.  I deployed the assembly and ran my custom STSADM command and then the Visual Studio Just-In-Time Debugger window popped up as expected.

Since I had already had the code project open I just highlighted that line and clicked the "Yes" button to debug my code.  If I didn't have the code project already open then I would click "New instance of Visual Studio 2005" and the code would automatically loaded into Visual Studio 2005.  Even if you don't have the code project on the server but have the "obj" folder and all its content then debugging is still possible (at least from my experience it is).  When the debugger is ready your code will have a green arrow next to it like the image below.

At this point I usually hit the F10 key and then everything changes to the correct colors and everything works as normal. 

When I got the debugging working with my code it was a lot simpler to see what was wrong with the code.  Then I started to test all the different options for my custom command and the debugger launching all the time started to drive me nuts.  I guess everything is not perfect but then it dawned on me what if I just add a debug option to the command string.  Something like "-debug" and if that's present then launch the debugger.  I thought it could work so I added the extra code to my project to make it happen and compiled everything and moved the assembly into the GAC again.

I went and tried my command again without the debug option and everything ran like normal and then for the big test I add the debug option and the debugger launched and everything worked just as I hoped.  Now I have complete control when the debugger will launch and I will no longer have the nuisance of the debugger launching every time. 

This was a great learning experience for me in many different ways but it really helped me open my eyes on making things more functional and user friendly by taking a little extra time to think about what could be done.

Cheers