Вопрос

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?

Это было полезно?

Решение

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.

Другие советы

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.

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.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с sharepoint.stackexchange
scroll top