I recently had a client that was experiencing difficulties when attempting to edit web parts on certain pages in their Intranet site, running on SharePoint 2007. For starters, clicking on the web part’s Edit menu would make the browser window scroll back to the top of the page, rather than opening the Edit menu as it should. No big deal. Who needs to edit a web part, anyway?

If that wasn’t bad enough, any time they would drag and drop a web part to a different web part zone on the page, they would receive the wonderful “An unexpected error has occurred” error, preventing them from saving the changes to the page.

To add some madness to the mayhem, the issues only occur in Internet Explorer. Since IE is the only browser officially supported by SharePoint 2007, SharePoint uses a dumbed-down page editing interface in other browsers. While much less user-friendly, the simplified interface would allow my client to successfully edit and move web parts without encountering errors.

Troubleshooting the problem

As my first step in troubleshooting the problem, I edited the web.config file, turning off Custom Errors and enabling the stack trace output. The hope was that this information would point me in the right direction to solving the problem. While the new error message is much less cryptic than “unexpected error”, it was rather unexpected and perplexing at first.

“GUID should contain 32 digits with 4 dashes.” Gee, thanks! I know what a properly formatted GUID should look like, but a GUID is never used as user input on the page. Why is it passing in an invalid GUID to the SPWebPartManager? Shouldn’t SharePoint be able to keep track of these GUIDs on its own? This got me to thinking that something must be preventing SharePoint from determining the GUID of one of the web parts, thus causing the error. Buy why?

The page contained Rich Content area at the top with user-defined content in it, as well as a couple of Content Editor web parts, so I decided to investigate. And sure enough, I found the culprit.

When the user pasted in the HTML content for the Rich Content area, it must have been copied from a Content Editor web part at some point. Unfortunately, not only was the inner content of the web part pasted into the content area, but the outer wrapping DIV was pasted as well, including the ID of the previous web part. This was creating a conflict of web part IDs, causing the JavaScript function to fail when determining the GUIDs of the web parts on the page.

After removing the extra wrapping DIV and the ID from the content area and saving the page, the web parts began to function properly. If I took one lesson away from this scenario, it’s that users aren’t always careful about their input, and SharePoint is not good at offering help to the non-technical user. As with any Content Management System, SharePoint is prone to user error, one of the most difficult types of errors to troubleshoot.

The post SharePoint 2007: Troubleshooting ‘Unexpected Error’ while editing web parts 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.