Search This Blog

Friday, February 4, 2011

SharePoint Development in Visual Studio



SharePoint Development in Visual Studio



This article is one in a series of articles about the core WSS/MOSS concepts. This
series of articles is focused towards .NET developers who are embarking upon the
SharePoint development and who have no prior experience in writing code against
SharePoint.



SharePoint development is different than typical ASP.NET development. Some of the important differences are in the development and deployment of the code and the tools support.




This article discusses these issues; at first we will see how SharePoint development differs from the ASP.NET development and how we can create a solution structure in Visual Studio for SharePoint development; the same Visual Studio project structure is used by some of the code samples available on this site. After that we will see what tools are available for SharePoint development in Visual Studio.



Introduction



We all are used to the ASP.NET web development where we launch the Visual Studio, point our mouse and click on couple of menu items, select a Project Template, enter project name and path, and we get a web project or web site in which we could then add our own files.



When it comes to deployment, Visual Studio allows us to directly publish those files onto the deployment server or we could just XCopy files over to a folder share or some of us might create an Installer package (.msi file) that could then be run on the IIS server in order to install the web application's code.




Some of the artifacts that are produced during ASP.NET web application development are listed below.


  • ASPX Pages

  • ASMX Web Services

  • User Controls (ASCX)

  • Server Controls


  • Java Script

  • Images

  • Style Sheets

  • .config files

  • All or most of the above compiled in the form of assemblies





So far everything looks familiar to an ASP.NET developer but as soon as the same developer starts to develop something for SharePoint, the developer starts to face frustration because the landscape has changed drastically! New concepts, new way of creating pages and adding functionality to an application, tweaking complex XML files, manipulating XSL for certain UI operations, and completely different way to installing applications make the development in SharePoint challenging.



Read on to learn why the SharePoint development is different.


SharePoint Development



SharePoint is nothing but a smart ASP.NET 2.0 application which extends the ASP.NET framework by virtue of installing couple of custom components such as HTTP module, HTTP handler, Virtual Path provider, etc.




The end result? We have a provisioning engine that could be used for creating web sites based on the templates that come with it. Of course SharePoint offers more features but those are for some other day.



So what do we exactly mean by "SharePoint Development"? That means we want to write some code to extend the out-of-the-box functionality that comes with SharePoint. Following are some of the examples of SharePoint development.


  • Add custom ASPX pages that help users accomplish a business function. For example, a set of Order Entry pages which walk the user through a series of custom ASPX pages for gathering some data.

  • You want to develop a widget style control (read web part) that could be used on more than one page.

  • How about performing some operation through code whenever a user uploads a document to a SharePoint document library? This would require writing some code against the SharePoint object model using your preferred .NET language.


  • What if the built-in SharePoint lists don't fit the bill for the task that we have? This might require us to create a custom SharePoint list with custom Site Columns.

  • How about changing the look and feel of your SharePoint site to not look like SharePoint? This would require custom branding which would include creating

  • You don't like the built-in Search Results page and want to change that. This would require creating your own ASPX page which would be called by SharePoint.

  • None of the out-of-the-box workflows that come with SharePoint are good for your needs and you want to write your own custom workflow.

  • How about encapsulating the company's revenue calculation logic in a custom User Defined Function (UDF) which could be used by the Excel Services?





And the list could go on and on. All of the above and countless more requirements would require you to write code against SharePoint.



There is couple of important points/intricacies that you should know in order to get some idea about the SharePoint development.



12 hive



Located at C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12, this is a special folder which contains the files used by SharePoint. This folder contains many other folders and each of those folders has its own purpose.




For developers, the very important folder is the sub-folder named TEMPLATE. So what is so important about this folder?



Well, the files needed by SharePoint to provide its own functionalities are stored here; similarly, the outcome of the most of the SharePoint development done by you would probably end up under one of the sub-folders under TEMPLATE.



For example, if you have created User Controls (.ascx) then those user controls should go under the CONTROLTEMPLATES folder. Similarly, if your user controls or ASPX pages need some images then those images need to go under the IMAGES folder; if you have created custom field types then those the XML files related to those need to go under the XML folder, etc. As you can see from that every folder has a specific purpose and contains a particular type of files.




Memorize the 12-hive path or better yet add a short-cut to it somewhere; you would be browsing that folder (and its sub-folders) quite often.




XML based development



Whether you like it or not, SharePoint development involves playing with XML files; in fact a lot of XML files! SharePoint has defined several XML schemas for creating different SharePoint elements and for performing different operations in SharePoint. For example, if you want to create a Site Column then you are required to use a particular XML syntax – see the Site Columns in WSS 3.0 and MOSS 2007 article for more information about creating custom Site Columns.




Similarly, if you want to extend SharePoint by adding couple of ASPX pages, user controls or other artifacts that you have to use the FEATURES schema to do that.



There are times when you would have to write the XSL code in order to manipulate the output of some of the built-in web parts. This again requires dealing with a particular XML syntax.




No F-5 Debugging




Every Visual Studio developer loves the F5 debugging feature where Visual Studio automatically attaches debugger to the process that needs to be debugged and all you are required to do is put the break-points before hitting F5.



Visual Studio does not have that seamless debugging experience during SharePoint development. You can't just press F5 and expect to debug your SharePoint related ASPX page or user controls.




No out-of-the-box Visual Studio Project Templates



Visual Studio does not come with pre-built templates for creating the SharePoint related projects. Microsoft has made available Visual Studio Extensions for WSS 3.0 which adds project template support for WSS and SharePoint development in Visual Studio.




How about the time period during which those extensions were not available? How did the developers go about creating code for extending SharePoint? See the section Custom Project Structure for SharePoint Development for more information.




Deployment



As you know now that SharePoint requires files to be copied under certain folders in order to use them. One of the ways this can be achieved is by using the batch files (as we will see later on) but this is not the recommended approach.




WSS 3.0 introduced a new concept called WSS Solution Framework which is nothing but a way for you to package all of the artifacts (DLLs, ASPX pages, images, XML files, and any other files which were produced during the development phase) in one consolidated .wsp file (normally referred to as the Solution Package). SharePoint and the tools that come with it (Central Administration web site and stsadm) know how to consume such file and how to process the files contained in it. You would have to use those tools to add and deploy the .wsp file in SharePoint. After the .wsp file has been deployed by SharePoint, you are guaranteed to have your custom code and files copied over to the appropriate SharePoint folders.



Again, the creation of .wsp file involves playing with yet another XML schema and a separate tool called MakeCab.exe (technically the .wsp file is nothing but a Cabinet file with extension .wsp).




So now you know some of the intricacies involved in the SharePoint development. Now let's discuss the project structure that you could use for SharePoint development in Visual Studio.



Custom Project Structure for SharePoint Development




In this section we will discuss the custom project structure for SharePoint development. During the course of the discussion, we will also walk through step-by-step instructions for creating such a project in Visual Studio.



Note that this project structure and the technique used here were learned from Ted Pattison and Dan Larson's excellent book Inside Microsoft Windows SharePoint Services 3.0.




Step 1 – Create a Web Project or Web Site



Launch Visual Studio and create a Web Project or Web Site. Delete the file(s) that Visual Studio generates by default. Your project structure should look like the following.





Fig 1 – Blank Visual Studio Project


Step 2 – Create the folder structure




Since SharePoint requires files to be deployed in certain folders in order to use them; that means we would have to duplicate that folder structure here under Visual Studio. Remember our discussion above about the 12-hive? That's what you need to duplicate under your project. Note that you don't have to duplicate complete folder structure including all of the sub-folders; rather the idea here is to start to add the folders that you would need (and this would be determined by the type of SharePoint artifact that you are going to create).



Based on our experience, we found that the developers used the following folders quite extensively. But this is not to say you would not have to use the other folders – you could if you are working on a SharePoint artifact that requires you to copy files under that particular folder.


  • […]\12\TEMPLATE\CONTROLTEMPLATES – for User Controls (.ascx)

  • […]\12\TEMPLATE\FEATURES – for Custom Features.

  • […]\12\TEMPLATE\IMAGES – for images.


  • […]\12\TEMPLATE\LAYOUTS – for "Application" pages (this will be covered in another article).






Fig 2 – Visual Studio Project with 12-hive folders



Step 3 – Create folder(s) for custom Feature



Take our word for it. You would be creating SharePoint Features for rolling out your custom code. So what should you do to create a Feature? Just add a sub-folder under the FEATURES folder for your feature and add the associated files and that's pretty much it!




For example, let's say you want to deploy couple of custom "Application Pages" which provide some new functionality which was missing in SharePoint. You need to create a feature for that and your feature name is TechConceptionApplicationPages. The folder structure for this Feature would be as follows (after creating a sub-folder under the FEATURES folder)





Fig 3 – Custom Feature sub-folder


Now you should add the supporting files for the feature under this folder. In case you don't know, at minimum, a Feature needs to have a feature.xml file in the Feature folder.



All right, so far we have created a sub-folder for our Feature. What if the project that you are working on requires you to use couple of images, user controls and ASPX pages? Where should those go? As explained above, every artifact needs to go in an appropriate folder.


Let's take an example. Let's suppose our TechConceptionApplicationPages Feature needs an image, two user controls and one ASPX page. So how would the project structure look like to accommodate all those files? It would look like as follows.





Fig 4 – Custom Feature and associated files under other sub-folders



As you can see that a sub-folder named TechConceptionApplicationPages has been created under each of the sub-folders (CONTROLTEMPLATES, IMAGES, and LAYOUTS). You must be asking was it done.



Your Feature with its supporting files will be deployed on the SharePoint server. Now let's suppose other developers are also creating their own Features and adding their own files. The files from all those developers would mix on the server if they don't create their own sub-folders to keep their files separate; in some cases, a developer might over-write the files created by some other developer! So this is a standard practice to create your own sub-folders to keep the files related to your Feature.


Did you also note that all of the sub-folders are named after the Feature name? This is not required but it is preferred so that you can quickly see which folders are related to your feature.



Step 4 – Create a batch file


So far we have created the folders for storing our files but note that none of the files have actually been copied under the 12-hive under Program Files folder; rather all of the above folders are created under the project folder.


The next task for us is to create a batch file that would perform the copying and other deployment related tasks “during development”. Please re-read the previous statement again; the emphasis is on “during development” because this is not the approach you should take for deploying applications on the productions servers. In future articles we will see how the code should be deployed onto the QA and/or production servers.


So what are the tasks that need to be performed in that batch file? First of all, we need to copy all of the files and folders that exist in our project to the 12-hive folder; and secondly we have to copy the output assembly from the project in GAC.



By the way, don't forget to generate an .snk file before building the application because an assembly cannot be deployed in GAC if it has not been strongly signed – and you would need a .snk file for an assembly to be strongly signed.


The typical batch file looks like the following. Note that some of the entries have been marked; these entries will change from implementation to implementation; rest of the code is just boiler-plate code which would remain the same.





Fig 5 – Post Build Batch File




Let's understand what is going on here.


Line 1 sets the variable to the path to the 12-hive; remember this is the place where all of the files need to go?



Line 2 sets the variable to the path to the stsadm.exe which is THE command line tool for performing administrative tasks against WSS and SharePoint.


Line 3 sets the variable to the path to the gacutil.exe which will be used for installing the DLL into GAC.


So the Line 6 simply calls the gacutil.exe and passes it the path to the project output file which in this case is SampleVisualStudioProject.dll. This line makes sure that the project output gets installed GAC.


Line 9 is interesting. Can you guess what is it doing? Yes, you are right. It is simply copying all of the files, folder, sub-folders from 12 sub-directory (which exist under the project folder) to the 12-hive which exists under Program Files (See Line 1 in the batch file). What does that mean? That means all of the files that we have added under CONTROLTEMPLATES, FEATURES, IMAGES, LAYOUTS or any other sub-folder will be copied over to the corresponding folder under SharePoint! What does that mean? That means we have just placed all of the files in the folders where SharePoint looks for the files.



Line 12 runs the installfeature operation using the stsadm.exe which basically tells SharePoint "Hey, this is the feature that I want you to keep an eye on; somebody might need it." Copying files under the 12-hive (Line 9) is only part of the story; we have to run the installfeature operation in order to make SharePoint use the files.


So the moment of truth has arrived. When the Line 13 runs, it actually activates your Feature onto one of the sites. This is the line where your custom code (e.g. Feature Receivers, etc) runs and this is the point when all of the provisioning happens.


But hey wait a minute. Who runs this batch file for all of the above magic to occur? I guess there is one more step to go.



Step 5 – Run a Post-Build Command



Right click on the project name in the Solution Explorer and select Properties. This shows the Project Properties screen. Select the Build Events tab and make sure it looks like as follows.





Fig 6 – Post Build Command



As you might already know, Visual Studio runs the Post-Build commands after successfully building the project. So this the best place for us to invoke the batch file that we created earlier because all of our code would have been compiled successfully by that time.


The first line in the post-build command makes the project directory the current directory so that the batch file could be invoked easily. The second line simply executes the batch file which in turn performs all of the operations that we discussed earlier.


Congratulations! You have created a project in Visual Studio for SharePoint development, have added couple of custom ASPX pages, user controls and images to the project and have created, installed and activated a Feature! Please note that this approach is good during development because this is not the way to deploy code to the QA and/or Production environments. In a future article, we will cover the preferred way of deploying your code to the QA and/or Production environments.



Tools Support for SharePoint Development


Tools support is important for a technology to pervade the developer community. If an extensive set of tools is available for a particular technology then the technology will be well received by the developers (adoption), they will take less time to develop the solutions (productivity), the code quality will improve resulting in fewer defects (quality), and of course they will be less frustrated (less turnover rate). In turn, all of this will enable quick delivery of software; reduce time-to-market and the happy customers.


ASP.NET developers enjoy extensive support in Visual Studio for the development of the web applications; apart from plethora of features at their disposal they also get the built-in project templates for creating the web applications, which is really slick.



On the other hand, Visual Studio lacks the support for SharePoint development, at least out-of-the-box it does not offer any project templates for SharePoint developers. Of course SharePoint applications could use many of the features available to ASP.NET developers (such as ASP.NET controls, Attach to process debugging, etc) but the thing that frustrates developers is the lack of proper project structure where they could add their own files.


Microsoft realized this gap and released a tool that adds some SharePoint development capabilities in Visual Studio. The tool is called Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions 1.1 which provides couple of Visual Studio Project Templates and the Item Templates for the commonly developed SharePoint artifacts. The User Guide and Samples for Visual Studio 2005 extensions for Windows SharePoint Services 3.0 are also available.


Apart from the above tool, there are some third party and/or open source software, utilities, project templates etc available that you can install in order to expedite the WSS/MOSS development in Visual Studio. The following is the list of my favorite tools from the CodePlex web site.





Other Resources




Check out the following SharePoint development related resources.