SharePoint 2010 Development Session 2 : Visual studio 2010 + the Sandbox

So here are some more notes I made after a second session learning about SharePoint 2010 development.  Do with them as you wish.

VS 2010 Installation

• SharePoint Visual studio 2010 developer tools are only for SharePoint 2010. The tools are built in to VS 2010 so there is nothing extra to down load and install once you have VS installed.
• There has to be SharePoint 2010 on the developer machine to do develop properly.
• VS 2010  with 2010 first glance benefits over MOSS and VS 2008
• The tools have been designed to cut down on a lot of the "wire up" procedures which where required in SharePoint 2007.
• A SharePoint explorer view has been added to allow browsing of SharePoint assets. This is available from Server explorer. You then have read access to SharePoint files.
• Most SharePoint development will start with a "Blank SharePoint project template". Which will then allow you to add all SharePoint artefacts as required.
• When adding features all the wire up is automatic. All the files required for a feature are created without the need to connect them together. Feature properties can be set easily through VS designer. This includes the name / scope / feature image url / and more. Its really is easy compared with MOSS.
• There are short cuts in solution explorer to allow you to add files to the rootfiles ( _layouts / _images / etc). This easily allows you to add files to the file system when needed. There is no configuring of XML required to tell the file where to go. Great!
• If you want to add an event receiver to a feature this is simple with a right click. The wire up is automatic and you are up and running quickly.

Deployment / debugging

• Everything is automatically packaged up into a .wsp file. This means that deployment of all changes is easy.
• F5 now allows debugging without attaching to process as was required in 2007 . When f5 is pressed the code is compiled, a solution package is created and deployed to the development server and full debugging mode is entered.
• It is possible to configure build patterns which allow you to specify whether to recycle IIS after deployment as well as a load of other options.

Web parts

Visual web parts allows you to create a web part containing and a user control. Similar to approaches in 2007 development but VS wires it all up nicely for you through the graphical designer.
 
Visual studio is extendible

  

There are extensions which are displayed under extension manager. Recommended extensions (from MSDN or Visual studio):

1. CKS - Development tools edition
2. VS 2010 SharePoint Power tools - Visual web part to sandbox. Aids sandbox installation.

Disposing of SharePoint objects

As we know it is important to dispose of SharePoint objects correctly or the whole farm can grind to a halt. A great tool for checking this is SPDiposeCheck / SPDisposeCheckStatic. The static version is a plug in for VS 2010 which can check that objects are disposed correctly.

http://spdisposecheckstatic.codeplx.com/.

Sandbox solutions

• Sandbox solutions allow development to take place in a safe environment known as a “Sandbox” The idea is that code which runs in the sandbox will not be able to do any serious damage to the running of the rest of the farm.
• There are limitations on what a developer can do in the sandbox. There is a subset of the object model available to make sure that developers cant cause any harm.
• Solutions are deployed at site collection level to a solution gallery. This task can be done by a site collection administrator so there is no need for farm administrators to get involved.
• In VS if you have selected "Sandbox solution" the intelisense will attempt to hide code not available in sandbox. Ultimately however there is no difference in the compiled code. It follows that a .wsp file is not targeted at a farm level or at sandbox level. There is no difference in the wsp. It is restricted by where the code is to run (either in the sandbox or not).
• Sandbox solutions can be banned from a farm by a farm admin if deemed to be dodgy.
• Visual web parts dont work in sandbox because of ascx deployment to the file system but the Power tools do have a way around this (see power tools extension mentioned above.

Things you cant do in the sandbox:

1. Modify file system
2. Access external sources (web services / databases etc) (although Sandbox proxy service can allow external access calls if really needed).

Things you can do in the sandbox:

1. Create Webparts
2. Create Lists
3. Create List templates
4. Create custom UI actions
5. Create some work flows
6. .... More YES

Solution execution

• Sandbox solutions don't have to run on the wfe they can run on another backend server.
• WFE will wait until the sandbox code has run and completed. There is a hard limit of 60 secs for this.
• The code runs under SPUCWorkerProcess process/.

WSP files (an aside really)

  

"Save as template" now saves as WSP file in the solution gallery. This can be opened in SharePoint designer. Sounds cool! From here you can customise the lists which are in there and so forth. Very flexible. Great for modifying site templates.

So that is my second quick session with 2010 development. Sorry its a bit notey but I doubt anyone will ever actually read it so it doesnt matter too much haha.

Bring on that SharePoint Farm