Sharepoint Objects

The best way to find out the properties of the Sharepoint objects is to use the reference pages on the web.

1. Place the cursor on "SPSite" in the .cs file in Visual Studio:  Press "F1" key:  A browser page should open on the reference for SPSite:
   
   
   
2. Google "SPSite" and choose the SPSite class item on MSDN

Note on the Class page the links to 

• Members
• Fields
• Methods

Browsing the members, will show what functions or data members are available for each object, and allow you to find the class type for other SharePoint objects.

Overview of some principle SharePoint Objects

SPSite

SPSite represents a SharePoint site and is usually the way into the SharePoint system (see examples), having said that we usually don't do much with it other than to access the SPWeb that contains the data in the site.
SPSite should be closed and disposed when finished with, so should be accessed through a using(){} block.

We can access the SPWeb object from the SPSite through the OpenWeb() function.

SPWeb

The SPWeb is one of the most useful objects as it contains the lists, the user info etc.  SPWEb should be closed and disposed when finished with so it best accessed through a using( ) {} block.

• CurrentUser gets information about the current user
• Lists is a collection that holds all the lists in the web / site (SPList)

SPList

SPList objects represent lists on the site.

• Items contains the rows (items) in the list
• Fields is a collection of SPField objects that define the columns/fields in the list
• Views is a collection of objects representing the views defined for the list

SPListItem

SPListItem represents the items in the SPList (see examples).  Note that there are two possible objects that can be used from a SPList.Items collection:  SPItem and SPListItem.  The List Item is the better class to use as it has member specific to the list.

SPUser

SPUser represents sharepoint users,and is used when want information about users, or to read or modify details of who last edited an object etc.

ASP.NET pages with SharePoint

Creating a first ASP.NET page

Assuming we have created a virtual directory for ASP.NET pages (Adding ASP.NET pages to a SharePoint Installation) we can now start adding ASP.NET pages.

• Using Visual Studio, create a new web site project on the folder created in the previous step.
  
  
  
• Add a Web Form (aspx page) to the folder:

• Add some content to the page (eg "Hello World") and save the page
   
• Verify that the page can be browsed using the SharePoint URL plus the new folder and name:

Adding SharePoint to our project

So far we have an ASPX page running on the SharePoint server, we now need to connect to the SharePoint system.

• Open the Code Behind (.cs) file and add "Using Microsoft.Sharepoint"

• This will cause an error (red line) initially as we need to add the reference to the SharePoint DLL on the server.
   
• Add a reference to your project:  Right click the project in the solution tree, and select "Add Reference", choose the "Browse" option and browse to the SharePoint DLL on the SharePoint server.

The Sharepoint DLL will be in c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI   (note \15\ is for Sharepoint 2013, use \14\ for SP 2010 etc)

• Select "Microsoft.Sharepoint.dll" and click "Add" to add the reference

• This will add several DLLs to the projects "Bin" folder and should clear the error on "Using Microsoft.Sharepoint" (after a pause)

NB  This only needs to be done once for the project, you don’t need to repeat this for every page.

Testing the SharePoint link

• Add a literal to the default.aspx page:
  
  
  
• Add code to the code behind Page_Load event:

Insert the URL of your Sharepoint site in the new SPSite function.
This code accesses the SharePoint site (the root site, but it doesn’t matter which site, as long as it is a valid site on your SharePoint installation.

Next it open the SPWeb object associated with this site and gets the current user from the web object.

The name of the current user is output to the literal.

• Save the page and browse to (or refresh) the page:

This demonstrates connection to the SharePoint system.

ASP.NET pages with SharePoint

Virtual Directory or Application

When adding ASP.NET pages to a site, you can create a virtual directory (ie a folder), or an application

Virtual Directory

Simple pages will be happy with just a virtual directory, but there are some limitations.

If you create a web project based on a virtual directory (as in the examples given here), you cannot have an app_code folder (or other app_ folders, app_bin etc).  This is because there is only one app_code folder at the root of the web: you aren't allowed to have a second app_code folder inside your virtual directory.

This means you can't use classes in your ASP.NET pages: class files go in the app_code folder.  If you setup a Visual Studio project based on the virtual directory, Visual Studio will let you add a class file, but it will create an app_code folder in your virtual directory to hold it.  This is not the "real" app_code folder, so files here won't be accessible at run time.
If you need to go this way, you could manually copy the contents of the "pseudo" app_code folder to the real app_code folder in the root of the site, but this would be pain to maintain.

You could point your webproject at the root of the sharepoint site … but this is probably not a good idea.

Application

An application however (is still a folder) but it can have it's own app_code (Etc) folder and this can contain class files.
So having a Visual Studio project on an application folder works OK.  You can create classes, put them in the app_Code folder and call the class as usual.

Which?

• I think, generally Visual Studio projects should be an application - this allows you to use classes etc as you should
• I have not -yet- found any disadvantages to using an application


See also http://www.iis.net/learn/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis 

ASP.NET pages with SharePoint

Adding ASP.NET pages to a SharePoint Installation

SharePoint runs under IIS, if you open IIS Manager on a SharePoint server you will see a typical SharePoint site, eg:

The first thing we need to do is add an application to hold our ASP.NET pages - this needs to be mapped to a folder on the server where we are going to store the ASP.NET files.

The name of the virtual directory must be unique and not match any existing folder, or any site in the SharePoint system.   (For example, we might have our SharePoint site at http://intranet and a sub-site at http://intranet/sales - so even though the folder "sales" does not occur in the IIS tree, we cannot use "Sales" as the name of our virtual directory.)

To create an application

• Create (or select) a folder on the server to hold the ASP.NET files:
  

New folder "E:\ASP-Pages" created to contain my ASP.NET files

• In IIS manager, right click the site and "Add Application":
  
   

• Give the new Application a name (Alias) - which must not conflict with any URL currently in use, and connect it to the new folder created above:

• Click "OK"

• Verify the virtual directory is set up correctly by creating a simple HTML page in the folder, eg test.htm:
   

<HTML>

<BODY>

Hello World!

</BODY>

</HTML>

29/10/2014 14:30 - Screen Clipping

• If the folder is correctly connected you should be able to open the test page in a browser by browsing to the SharePoint site and adding the new folder name and test page:
  
   

ASP.NET pages with SharePoint

SharePoint Development

ASP.NET pages with SharePoint

A relatively easy route into adding custom forms/screens to a SharePoint installation is to add ASP.NET pages to a SharePoint server.

Advantages

• Can use all ASP.NET features, controls etc
• Requires limited disruption to the SharePoint installation itself.
• Can access full SharePoint object model
• Runs under the SharePoint security model
• Can do things that aren't allowed under normal Sharepoint, eg
• Elevate permissions levels
• Overwrite fields such as "Modified By"

Disadvantages

• Debugging ASP.NET code not possible (as yet)
• Not fully integrated into SharePoint system (use IFrames)

• Adding ASP.NET pages to a SharePoint Installation
• Virtual Directory or Application
• Creating a first ASP.NET page
• Sharepoint Objects

SharePoint Development

Most code examples have been used with SharePoint 2013

SharePoint is a great platform.   But there are times when you need to add additional functionality, such as:

• Custom pages that display data in a different way to normal SharePoint pages
• Custom forms that manipulate data in a different way to a normal SharePoint form - eg some fields read-only
• Interface SharePoint data to other systems, eg sync or push/pull with an external data source
• Etc

There are many ways this can be done, including

• Develop SharePoint app using the SharePoint app module.
• Develop ASP.NET pages that interface with SharePoint
• Use external .NET tools, eg PowerShell to manipulate SharePoint data
• Use the SharePoint web services

These have various pros and cons

SharePoint Apps

Admittedly I haven't investigated SharePoint App development under SharePoint 2013 much, but I have developed apps for earlier versions of SharePoint.

• App development was complicated, needed complex (And picky) templates and config files
• You needed to have SharePoint on the development machine (or develop on the SharePoint machine)
• Deploying the app to the GAC folder meant you had to mess with the SharePoint .config and security settings

• But you could integrate nicely into a webpart, and use the SharePoint style configuration controls  and configuration storage.

I know with SP2013 there are more ways to develop webpart apps, and the deployment is different - but have not tried this.  I guess I ought to when I get the time.

ASP.NET pages to extend SharePoint

This is a relatively easy way to add functionality to SharePoint whilst retaining some of the look and feel (eg topbar / quicklaunch) of SharePoint.

The main catch is that the pages have to run on/from the same server as the SharePoint system in order to access the SharePoint object model.  For this reason the same issue applies as above about debugging, you can't debug the code unless you have SharePoint and visual studio on the same machine.  (Actually, I believe it can be done, but I haven't tried it don't know the implications)

PowerShell scripts to manipulate SharePoint data

PowerShell can interface to SharePoint and access SharePoint list data.

The script needs to run on the SharePoint server, but apart from that, this is a fairly easy way into simple access to SP data.

SharePoint Web Services

SharePoint ships with web services that can be used by an external system to access and update the SharePoint data.

These use a combination of SOAP, CAML and XML to request data and transfer results.

They can be called from a range of systems, including JavaScript (with or without Jquery), external program on another computer, PowerShell script on another computer,  ASP.NET application on another computer etc.

The big advantage of the web services is that they do not need to run on the same server as SharePoint itself, and are therefore much more flexible in where they can be used. 

The big disadvantage is that they are not easy to use, picky about syntax and often poorly documented (at least that was the case when I started using them under SP 2010)