views:

69

answers:

3

I’m after a bit of feedback with regards to using SharePoint Designer in production environments (I’m talking SharePoint 2007 here). There seem to be conflicting views amongst the SharePoint community with some advocating the tool as a valid means of “power users” customising layouts and building workflows whilst others take the view that using SPD effectively means developing in a production environment and it shouldn’t happen, full stop.

This is a tool obviously targeted at the type of users who are not typically going to go through a full application lifecycle of dev / stage / prod, particularly when they’re only looking to change a colour or insert a banner on a page. I hear the “don’t develop in production” message loud and clear but if that’s the case, where does it leave SPD? Is there a practical risk from its direct usage in a production environment? Should it be blocked? If so, who’s the intended audience and is there any place left for it at all?

+4  A: 

I have used sharepoint in a live enviroment and I would highly advise against it.

  1. It can crash randomly if you switch between code/design view after altering the code manually. IF you were to provide invalid markup it can cause it to crash, at least from my experience. This has caused me to get stuck in a mode of hald edited, half checked out status that left me waiting for sharepoint to be restarted on its next schedule before I was able to get back in and identify the issue.

It has also left me with corrupted files.

  1. I have accidently modified shared files without realizing the cascading effects. Fortunatley I was able to recover fast enough but the last thing you want is to get support calls because you accidently updated the wrong file.

In the end though it depends on how in depth you are pushing it, if you are going to stick in deisgn mode or use it for managing your workflow patterns then go ahead just tread lightly.

brian brinley
Bump - This is the reason why most knowledgeable SharePoint devs call it 'SharePoint Destroyer'. I've personally experienced the problems above and many more. Having said that, its good for 4 things 1) Creating source code quickly to copy paste out of 2) Working with 'ghosted' pages such as homepage layouts. 3) Looking at caching issues between sub sites (such as theme caching) 4) Working on Standalone html pages, very good html editor, it just goes mad when you connect it to SharePoint :)
Zeb
A: 

Occasionally we have to use it. If you are careful, you can avoid all the pitfalls as described in the previous answer. I usually keep a copy of the page code prior to modifications so I can roll back if necessary.

Please keep in mind the performance impact of making your pages unghosted as well. Once you modify a page in the designer it is detached from the site definition copy kept on the file system and needs to be loaded every time from the DB instead of the server cache, they say it could make the pages about 10-15% slower to load.

Vladi Gubler
A: 

For custom development in SharePoint, I recommend using either Solution Packages or SharePoint Designer, but not both. I prefer Solution Packages in an environment that has dev/test/prod servers, but without such an environment, I would probably lean toward SharePoint Designer over Solution Packages. Yes, it is possible for SharePoint Designer to put a site in a bad state, but not as quickly as the initial development iterations of a Solution Package can.

When using SharePoint Designer, you definitely need to control who has the ability to customize the site. SharePoint Designer 2007 is automatically limited because you needed to have a license in order to install it. While licensing can be a hassle (and expensive), it does have the benefit of giving you precise control over your audience.

EDIT:

SharePoint Designer 2007 is free as well. So for both SharePoint 2007 and SharePoint 2010, you will want to make sure that the environment is locked down so that casual users are not making unauthorized design changes to the site.

Rich Bennema