SharePoint Designer 2013 Crashing on Open Site: The Fix

The Problem

My Office365 tenant has become half-upgraded from SharePoint 2010 to SharePoint 2013. (If you want to read more of my whinging about this, checkout this thread on SPYam.)

This leaves me in the unenviable position of having to use SharePoint Designer 2013 (SPD2013) with my SharePoint 2010 Office 365 tenant. Unenviable because, as anyone who follows me even occasionally knows, the Design and Split Views are not available in SharePoint Designer 2013. That thread that I started on TechNet has over 28,000 views, so I don’t think that I’m the only one upset by this.

When I installed SPD2013 on my laptop, all went well. However, every time I tried to use the Open Site dialog, it would crash. SharePoint Designer 2010 (SPD2010) was still working fine when I accessed other 2010-based installations, but not SPD2013.

I found a fix that worked for me in the Technet forums. You may or may not want to trawl through the thread, as it is quite long. Instead, here’s the Cliff Notes version of what worked for me.

Sungmin Kim from Microsoft offered up this check.

You can repair your SPD 2010 to restore the regkey for SPD2010.

The issue might happen in case the ClientGUID of the Open Site dialog in SPD14 is the same as the one of the open site dialog in SPD 15 in a certain Side by Side environment.

(this repro’s only in a specific environment, but I couldn’t find the enviroment yet and when the GUIDs could be the same)

so I have couple of questions. Sorry to bother you, :(

1. Could you please check if ClientGUID value under HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site is the same as the ClientGUID value under HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site?

2. If the values are the same, could you please check if the crash still happens after removing both registry keys?

3. Have you ever installed any other version of SPD15 on your machine? (e.g. beta version) or any other version of SPD14?

4. if the issue still happens at #2, how about removing the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDLg32\LastVisitedPidlMRU ?

Points 1 and 2 did the trick for me. Apparently both SPD2010 and SPD2013 had the same GUID for the ClientGUID value in the registry. I had not installed any betas of SPD2013 on my laptop because I was concerned about exactly this sort of incompatibility. (I’d limited my use of SPD2013 to launching it inside virtual machines.)

The Fix

If you have this problem and want to fix it, here are the steps.

Open the Registry Editor. You can do this by going to the Start menu (I’m still a Windows 7 stalwart, so I can’t vouch for how this might work on Windows 8), choosing “Run”, and typing “regedit” in the Open: box.

Look for the keys:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site


HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Open Site

In my case, they were identical, as shown below.

SharePoint Designer 2010 (14.0)


SharePoint Designer 2013 (15.0)


Delete both of the ClientGUID keys. You can do this by highlighting the key and hitting the Delete key or right clicking and choosing Delete.

Once I had deleted these two registry keys, I was able to open sites in both versions of SharePoint Designer with no problems.

Unfortunately, the two versions of SharePoint Designer seem to use the same recent sites list, so I see the same Recent Sites in both versions. This is going to make it confusing when I am trying to figure out which site to open. Now I’m a three SharePoint Designer version guy, as I’m still using SPD2007 and SPD2010 for client work in addition to SPD2013. Yeesh.

Compound Filtering in Data View Web Parts (DVWPs) with SharePoint Designer

When you build a Data View Web Part (DVWP) in SharePoint Designer, there are times when you might need compound filtering. By this, I mean something like:

Show me the items where (City=”Abington” or Approval Status=”Approved”) and Approval Status!=”Pending”

It’s sort of a silly example, but you should get the gist. Where you put the parentheses matters. The silly example below says the same thing, but I’ve moved the parentheses:

Show me the items where City=”Abington” or (Approval Status=”Approved” and Approval Status!=”Pending”)

This would give you a different result, so you need some way to tell SharePoint Designer where the “parentheses” should go.

When you go to create this type of filter in SharePoint Designer, it’s virtually impossible to figure out how to do it. The UI for this is horrid.

What you need to do is select the rows you’d like to group together by using Shift-Click on each row. The rows must also be adjacent. Then you can either right click on the highlighted rows and choose Group or click the Group button below.clip_image002

Selecting the rows is the horrid UI part. One would have thought that this would have gotten better in SharePoint Designer 2010, but…no such luck.

Once you’ve done that, you’ll see a little blue bracket on the left, as below. The grouping is sort of like parentheses.


If you want to ungroup, you Right-Click again and choose Ungroup or highlight one of the rows and click the Ungroup button.

Changing the And to an Or or vice versa is a little bit easier to figure out, but it’s still horrid UI. You can click on the And, which will display a dropdown which allows you to change it to Or.


Depending on what selections you make, the filtering you set up this way will end up in the CAML for the DVWP, which is the most efficient way to filter. In some cases, your filtering will end up happening in the definition of the Rows variable, something like this:

<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row[@City = 'Abington']"/>

This is *usually* less efficient, but there are exceptions to everything; you still need to understand your information architecture to know what’s best. You can add this sort of filtering manually (I typed it myself in the example above) or check the “Add XSLT Filtering” box and then the “Edit” button.

In all of these cases, the UI leaves a lot to be desired, but you can get the job done if you persevere.

Creating a Linked Source for Your Data View Web Part (DVWP) in SharePoint Designer 2010

Matt Bramer (@IOnline247) asked me a good question today in the USPJ Academy forums which I needed to think about and do a little searching to answer. That usually makes for a good blog post.

I’ve tried to follow your aggregate data source steps in 2010 and I can’t seem to view a data source without actually inserting a DVWP. What is your approach to creating Linked Sources in 2010? I can do them within the GUI, but I’m sure you have a much better method.

Well, perhaps I’m a glutton for punishment, but I usually just build the AggregateDataSource (which is what you end up with in your DVWP if you create a Linked Source) in the code for my DVWP manually, whether in SharePoint Designer 2007 or 2010. I’ve done it so many times that it’s just faster and easier for me. That’s obviously not what Matt was looking for, nor is it what most others prefer, either.

In SharePoint Designer 2007, the Data Source Library showed up on the right side of the screen and it was easy to see how to use the different types of DataSources.


In SharePoint Designer 2010, we get more “help”. To me, that usually means that I can’t figure out how to do the same thing very easily. On the left pane when you open a site, you can see the types of objects you can interact with. (This is pretty similar to what you’ve seen in Access over the years if you’re familiar with that.) One of the options is Data Sources.


When you click on Data Sources, though, all you get to see are the site’s Lists and Document Libraries. But wait. Where are XML Web Services, Database Connections, etc? Oh yeah, now we have the ribbon. That oh-so-helpful ribbon. That’s where you’ll see the other types of Data Sources you’re used to.


BTW, note that XML Web Services (one of my favorite things) is now split out into two flavors: SOAP Service Connection and REST Service Connection.

XSL Is a Declarative Language – Why Do I Care?

Dreftymac ImageNode series. sample xslt file

Image via Wikipedia

One of the comments I sometimes get when I talk about the beauty of Data View Web Parts (DVWPs) in SharePoint is “You know, XSL is a declarative language, not a procedural one.” I gave a talk last night at the Boston Area SharePoint User Group (BASPUG) called Developing in SharePoint’s Middle Tier and it came up again so I thought I’d try to figure out a better way to respond than “Uh-huh”.

I turned to my esteemed colleague Ian Dicker (he thinks I should call what I do in the Middle Tier “middletation”) to see what I should think about this. Ian’s view is that XSL can be both declarative and procedural, and I concur. Of course, I couldn’t concur fully until I did a little Binging to try to find out what “declarative language” and “procedural language” meant and how they differed.  This is theoretical computer science stuff to me. Sure, I studied that in college (I majored in Computer Mathematics at the University of Pennsylvania, which was a hybrid math/computer science degree they offered at the time) but the theory of these things doesn’t play much of a role in my daily life. I usually just try to get things done. Well.

Turning to Wikipedia (everything there is true because it’s on the Internet):

Declarative programming

In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.[1] Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it.[2] This is in contrast with imperative programming, which requires an explicitly provided algorithm.

Procedural programming

Procedural programming can sometimes be used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions (not to be confused with mathematical functions, but similar to those used in functional programming) simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program’s execution, including by other procedures or itself.[1]

and thus

Imperative programming

In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way that imperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform.

(See the specific Wikipedia entries I’ve linked to above if you’d like to follow the citations.)

So, as in the title, why do I care? I think that the bottom line is that I don’t. But I also don’t agree that XSL can’t be used as a procedural language. I’m probably missing some of the nuances of the theory, but let me give an example.

SharePoint Designer sets up XSL templates itself and I do, too, in my custom solutions. An XSL template looks something like this:

<xsl:template name="StripHTML">
  <xsl:param name="HTMLText"/>
    <xsl:when test="contains($HTMLText, '&lt;')">
      <xsl:call-template name="StripHTML">
        <xsl:with-param name="HTMLText" select="concat(substring-before($HTMLText, '&lt;'), substring-after($HTMLText, '&gt;'))"/>
      <xsl:value-of select="$HTMLText"/>

This is an example from my SPXSLT Codeplex Project which strips all HTML tags from a chunk of text. It’s most often useful in displaying the Body of an Announcement without all of the goofy formating that the authors insist on using. It recursively calls itself until there are no more HTML tags to strip out the of chunk of text.  You call it like this:

<xsl:call-template name="StripHTML">
  <xsl:with-param name="HTMLText" select="@Body"/>

So based on the definitions above I suppose that this isn’t truly imperative (am I changing the program’s “state“? [Wikipedia: “In computer science and automata theory, a state is a unique configuration of information in a program or machine. It is a concept that occasionally extends into some forms of systems programming such as lexers and parsers.”), but it provides a reusable, procedural result. Again, I’m not sure if I care what the theoretical definition is, as long as I can use this template multiple times in the same DVWP, as needed. And I can, calling it with the @Title, @Body, and any other columns for which I need it, getting a consistently formatted chunk of text back, just the way I want it.

Are Ampersands Stored Differently in SharePoint 2010 Than SharePoint 2007?

I’ve always prided myself in building Data View Web Parts (DVWPs) that are bulletproof, meaning they will run and render no matter what. However, I ran into something today which gives me pause.

The setup on this is a little complicated, so bear with me. In SharePoint 2007, if you have a Lookup column which is based on a Single line of text column and that column value contains an ampersand, the ampersand is escaped in the DataSource for your DVWP.

So what does that mouthful actually mean? In this case, I’ve built some custom navigation on the home page of a site which is driven by three lists. Here’s a partial screenshot of the navigation the DVWP generates, obfuscated of course.


How the whole DVWP works is a different topic, but it’s a big hit with the person who manages it and the users love it, too. I did a webinar about how the whole thing works for the USPJ Academy’s site  last month. You can still watch it at DataView Web Part Unlocked.

Here are two screen snippets from an AggregateDataSource in SharePoint Designer 2007.

image image

On the left, you see the Navigation Areas list, which has items for the highest level of the navigation. The one item you see has its Title=”Collaborations & Partners”. On the right, you see one item from the Navigation SubAreas list. The Navigation Area column is a Lookup column into the Title column in Navigation Areas. As you can see, the value which is returned from the DataSource is “Collaborations &amp; Partners”, so the ampersand is escaped.

In upgrading this site to SharePoint 2010, I see something different. Here are snippets from the exact same AggregateDataSource in SharePoint Designer 2010.

image image

Egad. The Lookup column on the right doesn’t have its ampersand escaped! I’ve been very careful in my DVWP to handle the ampersand situation, and I have a template in place in 2007 called FixAmpersands that replaces an ampersand (‘&’) with ‘&amp;’ so that I can do “joins” between the lists in XSL.

<xsl:template name="FixAmpersands">
  <xsl:param name="StringValue"/>
  <xsl:variable name="Ampersand" select="'&amp;'" />
    <xsl:when test="contains($StringValue, $Ampersand)">
      <xsl:value-of select="concat(substring-before($StringValue, $Ampersand), '&amp;amp;', substring-after($StringValue, $Ampersand))"/>
      <xsl:value-of select="$StringValue"/>

So the net-net of this is that it looks like the ampersand is not escaped in SharePoint 2010 DataSources in SharePoint Designer 2010. It’s easy to fix on this case, because I can simply remove the FixAmpersands stuff, since I no longer need it. What concerns me more is that the DataSource seems to have changed from 2007 to 2010. Anyone else seen anything like this?