To code or not to code?

Question

I'm very new to SharePoint 2010. I just reviewed some resources. There's two general ways to deliver a sharepoint solution:

1. setup a sharepoint site collection, sites, lists, libraries, workflows,... via Sharepoint designer and also do some setups on the site using a web browser.
2. opening Visual Studio and start code to add and customize sites, libraries and so on. Then deploy packages of features.

I really don't know, when I have to open Visual Studio and code, and when I should do setups using sharepoint site itself.

What's your recommendation?

Answer 1

Basically, you can create solutions for sharepoint in visual studio, or by simple clicking in SharePoint Designer or by web browser.

As @Amadeo Gallardo said, it depends on project specification. If it's simple project, with does not require any features that sharepoint doesn't offer out of the box, the second approach is better and faster.

Creating sites, document libraries and SIMPLE workflows using web browser is much faster than visual studio. However, you must know that SharePoint Designer is very limited tool. Only basic workflows can be created using Designer. It was probably designed to be used by Power User or Designer. Also, in my personal opinion - is bad tool. Works awfully slow, it like to crash without reason, and has funny "Advanced view" which allows you to... edit html code. However you should know how to use Designer, sometimes it can be useful, especially for managing lists.

In answer to main question, "To code or not to code". We choose only visual studio development path. Why?

• Everything is organized as Features that may be activated / deactivated where you need them. Also, they can be set as "hidden" so user won't be able to activate them without using powershell.
• We create lists and libraries only using code. It allows to easily manage these list - content types, fields, views, injecting webparts in list forms.
• Content types are created using visual studio, because we use custom field iterators and validation for fields.
• Using Visual Studio you can create any workflow - basiclly, you have much more "items" (Activities) in workflow designer, even that allows you to run custom code.

In response to some comments mentioned higher: You can export/import sites as wsp. However, when your site is using Features, they probably won't work on site missing these Features. I'm not sure about it, but custom Features are not included when you export site as template by UI.

In conclusion

You can create sharepoint solution using only web browser. Many things cannot be done using UI, here with help comes SharePoint Designer. However, it is also limited, although you do not have to know how to code. Just simple click and drop.

Visual Studio is the most advanced approach to sharepoint, which allows you to do nearly anything. There are some things that cannot be done, or will just require you to spend many hours hacking - anyway, you will get used to it.

Answer 2

I've found it's best to avoid custom code whenever possible (or at least that seems to be the recommendation of a lot of people in the industry, mostly because of the complications it can introduce... think migrations). Contrary to Aljoscha's opinion, I very very rarely use SPD unless I'm required to in order to achieve what I need to. I feel SPD to be extremely overrated.

Visual Studio should be your go to application for custom development, but almost everything else can be handled through the SharePoint UI.

Any custom event receivers, custom field types, custom content types, and custom applications will (or should) be created in Visual Studio. Additionally, custom list definitions and instances can be created in VS, but I usually only use this method if I want to bake them in to a custom application and have certain lists automatically deployed when the WSP is.

Site build out, configuration, and administration can be performed through the UI and a little bit of PowerShell.

Answer 3

It depends on several factors. Here would be a very general overview of when each approach applies.

Visual Studio Solution

• Requires a developer with experience in C#, ASP.NET, Visual Studio and, of course, SharePoint and SharePoint Object Model.
• Solutions are more portable since they are packaged in a .wsp file that can be deployed anytime, anywhere.
• You can use a Source Control technology to keep your code safe and have versioning of the files.
• The components can be neatly organized in Features that may be activated/deactivated on the site after deployment (i.e. you can put WebParts in a feature, master page and page layouts in a Branding feature, etc.).
• More power for customizations: there are some components that can be only created in Visual Studio (List Definitions, State Machine Workflows, Custom Field Types, among others).
• Can be used to extend SharePoint base functionality.

SharePoint Designer

• More oriented to a Power User, Designer, Content Administrator.
• Ability to brand the site: modify Master Pages and Page Layouts, change CSS styles, etc.
• Really useful to manage an existing site without needing to write complex code that manipulates the SharePoint Object Model.
• Ability to create Workflows.
• Generally more powerful than using the SharePoint UI.
• Difficult to recreate modifications in another environment (i.e. not very reliable to export the current environment into another one).

Of course, these are just some of the differences between the 2 approaches. You can find more info in http://msdn.microsoft.com/en-us/library/ee558875.aspx and there are also a lot of references to this matter in Google.

Answer 4

In gerneral most people use SharePoint Designer to do the things that are possible with this tool and Visual Studio for everything else, because with it you can do nearly everything you can imagine.

SharePoint Designer was made for people who can't code but want to design own solutions without the help of programers, but Visual Studio can do the same stuff aswell (with code).

SharePoint Designer = simple

Visual Studio = powerful

Answer 5

I like to put as much as I can into features and packages. I mainly use Visual Studio but sometimes I will use SharePoint Designer to quickly create and export lists/sites, which I then deploy using Visual Studio.

Answer 6

I'd like to add, in my opinion, you only develop code in Visual Studios to solve a problem that SharePoint cannot do OOTB or with SharePoint Designer. Developing code and solutions can be a nightmare whenever you plan to upgrade/migrate or make server changes.