In sticking with our theme of debugging things from yesterday, I thought I
would write up a quick post on how to debug a cmdlet. This may be obvious
to you experienced developers out there, but someone new to writing cmdlets
may not be familiar with the process. Luckily, cmdlets are easier to debug
than the Custom Index Connectors I talked about yesterday. I hope to
educate people as much as I can on how to build cmdlets, so that we can get
more contributions to the SharePoint PowerShell Community Toolkit. If you
haven’t checked it out yet, please do. :-)
Once you have built your cmdlet, set a breakpoint in your code in Visual
Studio. Once you have done that, open a new PowerShell window (or a
SharePoint Management Shell) and install your module or snapin. The
technique for debugging is the same whether you load your cmdlet with
Add-PSSnapin or Import-Module.... (more)
Anyone else out there notice that if you add an generic handler to your
project that it won’t compile? It appears to be an issue with the
template included in Visual Studio and it may have been resolved in a service
pack but currently I don’t think so. The file type I am describing is the
.ashx generic handler and not the ASP.NET Handler as you can see below.
After it creates the file you might immediately notice there are issues. If
you go to compile it, you’ll get errors like seen below.
Luckily, resolving the error is quite easy. You just need to add
System.Web.Services ... (more)
This week, I needed to deploy lookup columns to some of my lists and as usual
I wanted to avoid writing code at all costs.
As some of you may know, Kyle Kelin and I debate this topic often as he
prefers a code approach. I figured it had to be possible with CAML, but
many claimed it was not even possible. A few approaches showed up out there
involving using code to modify the elements.xml file with your GUID, but that
just wasn’t going to cut it for me.
One popular post on the topic by Josh Gaffey, started me in the right
direction, but there were a few hurdles I ran into as ... (more)
If you’re a SharePoint person, you of course have the following path burned
into your memory forever.
C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\12
Well pretty soon, you can replace that with:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14
Apparently, Microsoft thought the number thirteen was unlucky. Now, I know
they are trying to rebrand this as the SharePoint root (or something like
that), but we all know that is never going to sick, so I’ll just call it
the 14 hive. Anyhow, this is the new place you’ll be doing a lot of your ... (more)
SharePoint on Ulitzer
This is already starting to be an interesting topic, so I wanted to post
about it. We’ll start with the facts.
SharePoint 2010 only runs on 64 bit operating systems In the past, SharePoint
developers have pretty much always had to develop in a virtual environment
Windows Virtual PC does not support 64 bit guests but other non-Microsoft
virtualization technologies do SharePoint 2010 can run on Windows 7 / Vista
x64 Most developers do not want to run a server OS on their development
machine Some developers may still be running 32 bit operating systems (ack!)