SharePoint Designer, and its predecessor FrontPage, has been much maligned by professional developers. Forced to step outside their comfort zone (Visual Studio), they resent the fact that they have to use a tool which is clearly targeted to Power Users, and not professional developers. Aside from various stability issues and missing functionality in previous versions, SharePoint Designer doesn’t even play lip service to the idea that you may not think it is a good idea to develop directly onto production systems. You might say that the tool’s designers completely missed that use case.

SharePoint Designer 2010 does go some way to fixing this. By changing the focus of the product to be more of a management tool, and providing high quality tools embedded within Visual Studio, developers will find that they will not need to use SPD much for development. Despite this, I still see a number of key scenarios where SPD will be used:

1. As a Proof of Concept / Rapid Application Development tool. SPD has always been good at this scenario, but SPD 2010 is even better. The ability to create and manipulate content types, lists (including external lists) and other SharePoint assets in the same tool is fantastic for developer productivity. It is a huge step forward, and this will be a key mechanism to hit the ground running.
2. To use the wizards and tools to build custom XSLT. SPD has some fantastic tooling for this, and if you lack the will to get your hands dirty playing with raw XSLT, SPD provides some killer productivity improvements. These tools are not available in Visual Studio.
3. As a workflow creation tool. SPD 2007 had some key weaknesses for developing workflows, not least a lack of reusability once you had built your workflow. SPD 2010 solves this by introducing reusable workflows, and the ability to save workflows out as WSPs.
4. As a way of increasing end user self-service. A tricky one this; giving end users the ability to mess up your deployment gave us issues when it came to governance and management. I’ve seen instances where there were 15,000+ customized web part pages in a single SharePoint site collection. Thankfully, 2010 brings us new ways of controlling this – and the best one is the ability to lock it down so that the end users can make use of the features of SPD where they need, but cannot, for example, go into the Advanced Edit screens. This increased granularity of control will make it more likely that SPD will be allowed to be used on production environments.

There are still some issues, though. The integration between SPD and Visual Studio is weak, and once you have moved from your SPD world into VS, there isn’t a clean way to move back into SPD. Furthermore, there is no integration with source control systems or continuous integration systems in SPD, so at some point on a professional project you should end up moving fully into Visual Studio.

I’ve been looking into one of the core missing features from the Visual Studio tools for SharePoint 2010. A really common scenario I have is that you hack together a page layout, master page or site page in SPD (or the browser, for that matter) and then want to package that for deployment or integrate with your development processes in Visual Studio. This should be really simple to do; I do it on every publishing project I do, but it is not intuitive in the new tools.

One way to do this is to package up the library into a WSP, and then import that into a Visual Studio project. This isn’t ideal since it brings across a large amount of stuff you don’t need.

Another option might be to make use of the SharePoint Explorer in Visual Studio to bring that stuff over. But no dice. The server explorer doesn’t give you any useful interaction with a project.

The end game for this blog post series is to have that scenario played out completely. But in the meantime, how would you do this manually anyway? Becky Bertrum has a good post on this here, and as you can see, it’s a pretty manual process. Some key points are just not intuitive enough.

1. Creating a module. This is fine, but having to manually update the module address to be “_catalogs/masterpage” is OK for people who previously had to create these by hand. For new developers, this is a pretty unintuitive step.
2. Creating the page layout / master page. Having to create a text file and then rename it with a new (.aspx or .master) extension is pretty lame.
3. Giving the page layout an associated publishing content type. While better than the old way [go and grab a query string from a URL on the Site Settings area], it is still too hard to get the content type’s ID via Visual Studio.
4. Adding SharePoint assets to the page. Now you have to actually work with the page layout and make it do what you want. Again, this is easier said than done. Ideally, you’d be able to drill down in the Explorer to Site Pages, Site Assets and the Master Page gallery, right click and say “add this to my project”.

So, what’s to be done with this state of affairs. Thankfully, the SharePoint Visual Studio tools team bought into the extensibility framework that VS2010 delivers. We can change the behaviour of Visual Studio to do what we want to do.

There are a number of distinct tasks I think would be very cool extensions:

1. Provide a new item type called “SharePoint Publishing Module”. This will automatically set up the correct paths for the master page gallery.
2. Provide a new item types called “SharePoint Publishing Page Layout”, “SharePoint Master Page” and “SharePoint Site Page”.
3. Provide a right click action on Content Types and Fields in the SharePoint Explorer to provide a “Copy ID to clipboard” function.
4. Provide the ability to drag master pages, page layouts and site pages from the SP Explorer into VS modules.

The rest of this series will provide examples of how to do each of these.