I am part of a team working on a large, heavily customized SharePoint 2010 publishing site using TFS for source control and a mixture of Visual Studio and SharePoint Designer for development.

One team member who doesn't have experience using Visual Studio / creating sites in code, but is excellent with using SharePoint Designer's WYSIWYG editor, wants to work on developing some of the templates. We can't however figure out how this team member can check out from TFS and edit a file (e.g. a SharePoint page template) using SharePoint Designer.

The issue is that editing an individual template locally doesn't work well using SharePoint Designer, as it won't render properly unless it is part of a site with a Master Page and other things which the template references.

The closest we have got to a working process is:

  • Check out the file in question from TFS using Visual Studio (or the VS Power Tools Explorer extension).
  • Import the file into an already-working SharePoint development environment running on the developer's local machine.
  • Edit the file using SharePoint Designer as a WYSIWYG editor.
  • Save the file from the development environment.
  • Manually copy the file into the TFS working copy, overwriting the previous version, and then check in.

This seems really time consuming and prone to manual error. Are we missing something?

4 Answers 4


There isn't much you can do to improve this workflow, although a stand-alone TFS client will make it a little easier. SharePoint Designer is a great tool for working with artefacts and customizations in the content database, but is not really designed to work as a development environment. It needs to work in the context of a functioning site.

You also need to be clear about which items will be source controlled as development artefacts, and which will be content. The latter will be versioned in the content database. Not everything needs to be in source control.

  • I've sat in some ALM discussions where SPD was mentioned and there doesn't seem to be any real desire to incorporate SPD artifacts in the TFS story so I wouldn't expect this to change much. Nov 15, 2011 at 23:32
  • We're going to stick with the clunky workflow I described above. Thanks for the confirmation that it's as good as it gets :(
    – Nick
    Nov 22, 2011 at 9:31

Check this post in SO, some standalone TFS client exist that can help checking in and out of TFS. As far as I know, no TFS plugin exist for Designer since the vast majority of Designer are not using VS2010 or TFS at all.


The short answer is that whatever is output from SharePoint Designer needs to be routed through Visual Studio and packaged for deployment. I use SD2007 only to "interrogate" the CSS/markup; I religiously avoid saving anything in this tool. I do all my actual design work in Visual Studio where master pages, CSS and the like can be created as Features and deployed as solutions.

You cannot afford to sacrifice your development workflow and source control just because of one team member. There is nothing in HTML/CSS that cannot be done in VS anyway, so I fail to see the problem.

  • I would disagree - there are many tasks that SPD does well that would be extremely difficult to achieve using VS. Also not everyone has VS skills - they may not even be a developer but a web designer, for example.
    – SPDoctor
    Nov 16, 2011 at 9:14
  • VS skills? At the end of the day it's just a text editor. A Web Designer who is not conversant in HTML/CSS is not a Web Designer and I think the fact that Nick is experiencing this problem in the first place speaks volumes :) Nov 16, 2011 at 14:41

SPD is so much more than a text editor. I use a mix of VS and SPD, and it's helpful to know both. There are drawbacks to doing everything in VS, but when you're a hammer, every problem looks like a nail.

Best to take a modular approach to such development. Some components are best developed in the native UI, some in SPD, some in VS. I typically only use VS for integration components, event receivers, timer jobs, etc.

Generally, it's expected that solutions developed in VS will break when you upgrade. Things done in SPD (using jQuery and SP REST Services) are more robust. Additionally, SPD development allows you to augment things while data is in flight. If you do all your dev in VS, then you will only be able to augment in VS, and will be forced to redeploy, potentially skunking ongoing processes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.