One of the things I love about my job is that satisfying feeling of accomplishment that I get when I solve one of SharePoint’s quirky difficulties. If it weren’t for this feeling of euphoria that comes along every so often, I’d have gone insane long ago. Thankfully, SharePoint has no shortage of strange behavior and head-scratching moments.

One of my colleagues recently ran into a strange error while developing a custom Application Page. No matter how he was catching and handling runtime errors, every time an exception was raised during the Page Load event, the page would crash, displaying a perplexing error message and stack trace.

Specifically, he’d receive a “No item exists at <url>. It may have been deleted or renamed by another user” error. What item? The one that the page isn’t using at all? Obviously. The corresponding stack trace wasn’t too helpful either. When stepping through the debugger, it was clear that the Page Load event was executing successfully, but the page was still crashing, even when the entire method was wrapped in a try/catch block with proper exception handling.

At this point, I thought of something. The page was utilizing query string parameters to receive data and pass data to itself across postbacks, so perhaps something was wrong with one of the parameters? I noticed one of the parameters he was using was named “ID”. I suggested we change the name of this parameter to something else, and lo and behold, the problem was solved.

The Moral of The Story

For reasons I still don’t quite understand, although it does sort of make sense, the “ID” query string parameter is a reserved keyword in SharePoint. Any time this parameter is present, SharePoint tries to do something internally, which sometimes makes it take a crap. Oddly enough, the problem only happens when an exception is raised during code execution, regardless of error handling. The moral of this story is to NEVER use a query string parameter named “ID” while developing for SharePoint.

There are several other query string parameters one should not use as well, and most (but not all) of them are far more obvious than the ambiguously-named “ID” parameter:

• FeatureId
• ListTemplate
• List
• ID
• VersionNo
• ContentTypeId
• RootFolder
• View
• FolderCTID
• Mode
• Type
• PageVersion
• IsDlg
• Title
• _V3List_

(Thanks to Stefan Goßner over at TechNet Blogs for this list.)

The post SharePoint 2010: Mysterious Errors Using Query String Parameters first appeared on Techerator.

Unfortunately, SharePoint development requires many DLL files which are included with an installation of SharePoint on a server.  To make matters worse, SharePoint 2010 requires an x64 server, further complicating the issue.  Fortunately, there is an easy workaround that can allow a SharePoint developer to be productive, even while using their laptop on the road without an available internet connection.

Copy the SharePoint DLLs

As I mentioned before, SharePoint development requires DLL files that are included with a SharePoint 2007 or 2010 installation.  The first step is to grab these off of a SharePoint server.  For SharePoint 2007, they are located in the hive at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\, and for 2010 at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAP\.  Copy the DLL files in this directory from the server, and paste them at the exact same file path on your local machine.  Since your PC likely does not have SharePoint installed, you may have to create the directory structure yourself.

Register the Assemblies to the GAC

Now that you have the DLL files on your workstation, you will be able to include them as references in your Visual Studio projects just as you would with any other DLLs.  However, if you want them to auto-register with your project when you use a Visual Studio 2010 SharePoint template or a WSPBuilder template, you must register the DLL files in your local Global Assembly Cache.  To do this, open the directory on your workstation that contains the SharePoint DLLs and drag them into the C:\Windows\assembly\ directory.  This will register them with the GAC on your workstation, and Visual Studio should successfully find the assemblies when a template is loaded up.  Although these assemblies may be 64-bit, this will work fine even though your workstation may be 32-bit.

If you’ve successfully completed the two steps above, you should be able to write your code and successfully compile your project.  Once you generate your WSP file, you can then deploy it like any other WSP.

Please Use Caution

If you do development for both 2007 and 2010, you can do this for both on the same workstation; just be sure to complete both steps for each version.  Since the 2007 and 2010 assemblies have different Assembly Versions (12.0.0.0 and 14.0.0.0), you don’t have to worry about conflicts in the GAC.  Be sure to use caution, however, because in my experience, Visual Studio tends to grab the SharePoint 2010 version of the DLL even for a SharePoint 2007 project if they’re both registered on your workstation.  If this happens, remove the incorrect reference, and add a reference to the correct 2007 DLL from your 12\ISAPI directory.

The post How to Perform SharePoint Development On A Client Workstation first appeared on Techerator.