A friend of mine asked me a very cool question: “how does an MCM troubleshoot and debug SharePoint?” Well, as simple as the question is, I prepared a big set of tips that I believe are extremely unpopular in the SP development space, yet extremely powerful if used in the right way.
I use these techniques in my everyday SP life both in development and when we do troubleshooting. This is a multi-part set of posts, where I’m going to start with some easy stuff, then increase the complexity:
Debugging and troubleshooting SharePoint
Part 1: Using a console listener during deployment (this post)
Part 2: Following the order of feature installation and activation
Part 3: Don’t forget about the Developer Dashboard!
Part 4: ULS troubleshooting tips
Part 6: Turn on Fusion logging to troubleshoot assembly loading/binding information
Part 7: Profiling SharePoint with the ASP.NET Profiler
Part 8: Collecting SharePoint intelligence with IntelliTrace
Part 9: Debugging SharePoint code execution with decompilers and reflection tools
Part 10: Debugging SharePoint memory dumps and live execution with WinDbg
Part 1) Use the Console Listener to send messages to PowerShell while deploying WSP’s:
This part is easy, but sometimes very helpful. I have created an awesome WSP that uses TraceListener to send output messages. It is a convenient way to get output to the console when deploying with PowerShell.
Some quick code:
//Quick lame check to ensure our listener is not there
//Add listener if it doesn’t exist
TextWriterTraceListener(System.Console.Out, CustomConsoleListener); //type console and name
Debug.Listeners.Add(writer); //register the Console listener
Version); //Send message to the console
In my feature I have:
ConsoleLogger.WriteToLog(DateTime.Now.ToString(“dd/MM/yyyy hh:mm:ss.fff tt”) +
” WebApplicationFeature2 FeatureActivated Event”
When deploying with PowerShell, you will see the following output:
(I have crossed out the name of my web application as it is “sensitive”, and I have many features.)
Note, the SharePoint Timer Process responsible for deployment of WSP’s without the –Local switch doesn’t have a console.
The above helps when figuring out deployment issues predominantly during development when you are trying to get things right.
Another very interesting point regarding this is the “Activate on Default” setting:
Activate on Default: It is only relevant to Farm and WebApplication scoped features. The deployment framework will automatically activate the feature if this is set to True and the scope is either Farm or Web Application. I blogged about it ages ago here: “Activate on Default” confusion and features scoped at Web Application level
HOWEVER, there is a slight gap here… if the solution is a Sandbox Solution, this setting will also trigger on features at the Site scope. Ignore the documentation, it doesn’t tell you this.
Always Force Install: this setting will get rid of the annoying message that tells you the feature is already activated at the scope. While it is very annoying during development, in a real-life production environment it makes a lot of sense. It reminds us that re-activating the feature will apply all feature elements and execute feature receiver code. Forcing the activating will suppress that message for features at any scope level.
Auto Activate in Central Admin: This setting name actually gets it right for once, it will automatically activate the feature at Web, Site or Web Application level on Central Administration.
Until next time, where I show how the feature activation order works.