The nature of deploying a sharepoint solution (or TO a sharepoint solution)

Question

I'm in the really early stages of learning sharepoint and I'm struggling with a few concepts. One of which is the way in which one builds/deploys/debugs a sharepoint solution. Prior to sharepoint I'm used to developing standard web apps in asp .net C#; during which - I was used to the fact that when building or debugging - the files that were being viewed by the end user were literally organised in directories within my solution and were the actual files - files you could easily see the structure of in VS (I'm trying to explain this the best I can).

Whereas now, I'm developing master pages, css, aspx pages and web parts, choosing to 'Deploy' and then browsing either from IIS or running with the debugger from Visual Studio 2010. But the way in which I'm deploying feels like I'm just carrying out some sort of file copying action (determined by what's in my elements.xml files, for example) and that's it. So is this solution directly 'linked' to a sharepoint solution or just 'temporarily' used to add files and function to it?

Answer 1

A SharePoint Solution (WSP file) is a compressed (.cab) file which contains all of your files (including dlls) and a Manifest.xml telling SharePoint about which files and Features is included.

"Deploying" this Solution to SharePoint is in fact a two step process

1. Add the Solution (which stores a copy of the WSP in the Configuration Database)
2. Deploy the Solution (which copies all the files to the right location (including GAC) and modifies web.config files on ALL the servers in the Farm including future servers which may be added and then installs all the Features)

Visual Studio hides some of this from you to make it "easy" to develop, and it's not that interesting on a development machine.

BUT this deployment framework is essential in a productions (and test) environment where you often have multiple servers and may add new ones later. When a server is added to a SharePoint farm SharePoint automatically downloads the files from the Configuration database and put everything in the right place on the new server before it's really added.

The main reason for doing all of this deployment on a development machine is to make sure it works (and later when you learn how it works you'll often shortcut some of it, but until then just do the full deployment)

Answer 2

Dan, Per answered your question. But, a helpful fyi: In your project, rightclick the project name and to go properties. You'll see a SharePoint tab. Click there. There is also a list for grouped deployment options. Click into the default item. There, you'll see the actions (scripts, either cmd or ps1) that visual studio performs when you click "deploy". Visual studio does these thigns for you, but in production, you will have to do them in CA and with scripts. Recently, with Per's help, I created a post command to my VS2010 deployment to stop and start some services to ease the deployment of my packages in dev. good luck.

Answer 3

@Daniel McNully

I have been working on a custom master page and web parts for a couple of weeks now and the way I do it as follows: Deploy to a web app (either sandbox or as farm; since I am on a dev environment, I deploy as a farm solution) and to answer your question, Yes every time you make any changes in the solution (I am assuming you are using Visual Studio 2010)and deploy, the changes will reflect as soon as you refresh your page. This shows that it is updating the solution and not creating a new copy of your solution every single time. I hope this answers your question but do let me know if I am off track.

Answer 4

There are multiple types of artifacts when working for SharePoint - which makes it "special". Sticking to the "Branding & Design" artifacts these are different because they would "complete/extend" SharePoint so you can see it as:

• You need to deploy additional artifacts (CSS, Master Page, Page Layouts - for Publishing sites or Web Parts page for Collaboration Sites) - which would replace the OOTB ones. Of course you need to follow standards and recommendations (here regular ASP.NET principles apply for Master Pages and Controls building). The main difference comes from how to "PUSH" these to SharePoint, due to hierarchical complexities (the whole site collection, one subside, etc.) and most important reusability concerns (moving from FARM to FARM, applying across Site Collections, etc.)
• This is where solution packages comes in place (.WSP) as the recommended way of deploying artifacts (otherwise you stick with doing these 1 time via SPD ). VS2010 has special components for packaging into a cab-like structure and combined with Features you get to control deployment behavior (visibility, application, etc.).

Hope this helps, C:\Marius