Just Add Code

K2, best known for their enterprise grade workflow engine, has recently released information on their latest product, K2 blackpoint.  They are positioning this product for use when you need something more powerful than SharePoint Designer, don’t want to write custom code and don’t need the advanced features (or cost) of their primary workflow product, K2 blackpearl.

I haven’t played extensively with it yet, but they do have a good overview video and a trial download to check out.  I’m looking forward to putting it through its paces in the coming weeks.

K2 is also having a little contest, like an internet scavenger hunt, where you can win prizes and everlasting internet fame.  In order to win, you need to find some images scattered across various sites, blogs and webcasts.  Luckily for you, you’ve found one such location.

I once heard an analogy that navigating a submarine was like painting
over all the windows in your car, cracking the window and a attempting
to drive somewhere using only sound.  Since I don’t have a sub handy I can’t speak to the accuracy of that, but sometimes debugging in SharePoint seems only slightly easier.

If you’ve ever created a FeatureReceiver, then you’ve probably also
had it not work.  There’s some code that’ll work right the first time
for you, that never seems to be a custom feature.  When the feature
doesn’t work you either don’t get the result you were expecting, or
worse, Something Bad Happened. Even if you assume that you’ve already got
your development environment set up so you can debug a web part, its
not immediately obvious how to debug that feature that’s causing your
problems.

Well, you’ve come to the right place!  Here’s a couple options to fix
up your broken feature:

Attach to w3wp (aka Its Still SharePoint)

 
If you’ve ever (successfully) debugged in SharePoint you are probably familiar with this approach.  Fire up visual studio and attach to the w3wp.exe process and then Activate the feature.  Setting a breakpoint in your FeatureActivated and activating the feature through the web UI works in the debugger like you’d expect, so why not just stick with this approach?  The biggest reason is you can’t do the same thing for FeatureInstalled or FeatureUninstalling.  Since you have to use STSADM for those actions, attaching to w3wp isn’t going to do anything for you.

Console/Debug.WriteLine (aka printf forever!)

Bring on that retro flavor!  Liberally sprinkle Console.WriteLine’s in your code and you’ll feel like you’ve been teleported back in time and you are writing a C based console app, or at least like a Response.Write from classic ASP.  Using the WriteLines you can ‘debug’ your code without the use of a debugger and you now have access to Installed and Uninstalling. If you are using stsadm, Console.WriteLine will work fine.  If you are activating via the web, or just don’t like other people to see your debugging messages you can use Debug.WriteLine and view the output with something like DebugView. The downside is you have to use STSADM to do your Installation and Deactivation and don’t really have the option of using a debugger if you wanted to.  You’ll have to be pretty quick to attach to the STSADM process before it finishes (or be on a really slow server).

Force the Debugger (aka The Easy Way)

 
The previous two options have each been useful but have had some pretty serious caveats to using them for everything, if only there was another way!.  Luckily there is, we can just force the debugger to run.  By putting the line System.Diagnostics.Debugger.Launch(); in our code, it’ll attempt to start the debugger.  This approach will work regardless of if you are using STSADM or the UI.  You’ll be presented with the "Launch Visual Studio" dialog.  If you’ve already got the project open, select your running instance of Visual Studio.  Otherwise open a new instance and browse to find your code.

These options should get you on the right track, and who knows, you might even
start like writing FeatureReceivers…or not.

Well, maybe not one hand behind your back, but what if you only have the ID of the web?  I received this question after presenting a session at the Twin Cities SharePoint Camp.  I knew you could grab an SPWeb if you knew its URL using SPSite.OpenWeb, but what if you only had the ID?

Worst case solution would be to recursively go through all the Webs and SubWebs in order to find one with a matching ID.  Another possible, though horrible, approach would be to query the SharePoint database and get the URL from that.  Both of those are pretty bad approaches to what is seemingly a simple problem.

After spending a couple minutes with the SDK I found there was a much cleaner approach available, SPSite.AllWebs.  SPSite has an AllWebs property that has ALL the webs under it, not just the top level ones.  It also has an indexer on it that takes in a guid, giving us our perfect Web by ID scenario.

PowerShell Code:

[system.reflection.assembly]::loadwithpartialname("microsoft.sharepoint")
$site = new-object Microsoft.SharePoint.SPSite("http://mysite/")
$siteid = new guid("22625614-bb87-4cb1-a817-52f8a7366640")
$web = $site.AllWebs[$siteid]
$web.Url

Result: http://mysite/toplevel/secondlevel/YouFoundMe

Success!

For the fourth Twin Cities Code Camp I gave a presentation on Extending PowerShell for developers.  Turnout was great yet again at Code Camp, pretty much every session filled up.  The enthusiasm of the people who attend these sessions really make it a fun place to present.  I had a great group in my session, they helped make it into a very interactive presentation.

I started with scripting in PowerShell, then moved into dynamically adding members (properties and functions) to objects.  The PS1XML file is available for download.  Additionally, if you were interested in another example of this, the PowerShell for SharePoint Developers session I did at DevConnections has another good example of where a PS1XML can be used.

A Cmdlet and SnapIn were created using David Aiken’s great PowerShell Visual Studio templates.  It demo’d passing parameters to a Cmdlet and having it return an array of items back to the Pipeline.  I also showed two implementations of hosting PowerShell; one for running a command from your app, and the other for replacing the UI entirely.

Slides
Code

One session down, two to go.  I got my first DevConnections session under my belt.  One of the things I’ll try to do is turn some of my slides and discussion points into charts/datasheets.  The feature ‘gotchas’ and ActivationDependency restrictions are excellent candidates for this.

As promised, here is the slide deck and code samples.  Enjoy!

Today was my first full day at DevConnections in Vegas.  I spent part of the day going to sessions, and squeezed some time in for some last minute work on my sessions.  Its been great to be here with some of my coworkers, including Mike who’s been posting some great updates of the conference.

My Speaking Schedule:

• Wednesday
• Advanced Feature Development
• When: 2:30pm
• Where: Mandalay Bay B
• Thursday
• Customizing the SharePoint Mobile Experience
• When: 11:15am
• Where: Mandalay Bay B
• PowerShell for SharePoint Developers
• When: 2pm
• Where Mandalay Bay B

I’ll be posting the slides and code for the sessions after I give them.

If you’re in town for DevConnections, drop me a line!

Last weekend I was able to present two sessions at the Twin Cities Code Camp. One on WebPart Development and the other on PowerShell.

WebPart Development Chalk Talk

I covered some common development scenarios: basic webparts, connectable webparts and using ASP User Controls with the SmartPart. I have all the code from the presentation.

Introduction to PowerShell

This session was hard to prepare for because I wanted to have everyone leave understanding all the great functionality of PowerShell and able to use it for more than a basic shell. I think it turned out pretty well. I was able to cover a lot of different areas of PowerShell in a reasonably coherent manner. The group seemed pretty interested and asked some really great questions. One of those questions taught me a valuable lesson: “Don’t do a recurse get-content to the screen unless you’re sure there aren’t any binary files in the directories”. During the course of attempting to answer a question I accidentally did a ‘get-content’ against a large ISO file. My computer wouldn’t stop beeping, no amount of CTRL-C or Task Kill would make it stop. I ended up having to do the last 5 minutes without my deck..presentations are always fun!

Special thanks to Karl for providing me with some copies of PowerShell Analyzer to give away to the attendees.
Links from the session:

• PowerShell Analyzer
• PowerTab
• Console
• PowerShell Community Extensions
• PowerShell Remoting

At the last Code Camp I presented on SharePoint, this time on WebParts and PowerShell…I think there’s a trend in me presenting on topics with BigLetters in their names. We’ll see what happens next time! Thanks again to Jason for putting everything together.

The PowerShell Remoting project now has a new home on CodePlex. Since GotDotNet is phasing out their workspaces, it was a good time to move the project over to CodePlex. I’m already enjoying the TFS based source control. There is also a good interface to use for bug tracking. Now is also a great time to request a new feature so we can get it into the next release.

Not familiar with the PowerShell Remoting project? PowerShell Remoting is a client/server app that allows you to use PowerShell to connect to another host and issue commands. Think of it as SSH for Windows, only instead of a something like an .rhosts file, you can log in with your domain credentials to skip entering a password. If you have to manage multiple machines, and you like PowerShell, this should probably be in your toolkit.

Here’s the presentation I did for the Twin Cities Code Camp around SharePoint as a Development Platform.

Welcome to those of you hitting here from the Twin Cities Code Camp. As you can probably see, there are a few cobwebs here.
I’ll be doing a presentation on using SharePoint as a Development Platform. With all the recent activity around the SharePoint 2007 release, developers (or at least their bosses) are more interested in how they can use SharePoint in their organization. I’ll be covering what things to consider when deciding whether or not to use SharePoint, and then how to actually develop againist it. There will be code examples for the three major approaches (object model, web services and RPC).
All the code and slides will be posted here for those who couldn’t make it, or really want to try out the code.