Home > Blogs > Eric Shupps | The SharePoint Cowboy > Posts > Designing Custom Development Solutions for SharePoint 2010
 
Eric Shupps eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational intelligence solutions for Microsoft SharePoint. Eric Shupps eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. he is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.sharepointcowboy.com. Presentations by Eric Shupps eshupps The SharePoint Cowboy Webinar - Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure featuring Eric Shupps Who are you and what do you want - Working with OAuth in SharePoint 2013 SharePoint is Talking Are You Listening? Eric Shupps SharePoint 2013 Performance Enhancements Taking Advantage of the SharePoint 2013 REST API Eric Shupps on Improving Performance with New Features in SharePoint 2013 SharePoint 2013 New and Improved Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure Eric Shupps Presents SharePoint 2013 Real World Help Desk App End to End Windows Azure Apps for SharePoint 2013 Eric Shupps Demonstrates Customizing the Visual Studio 2010 SharePoint Deployment Process Introduction to SharePoint Development SharePoint 2010 Unit and Integration Testing with Eric Shupps Building Enterprise Records Management Solutions for SharePoint 2010 Taming Information Chaos in SharePoint 2010 SharePoint 2010 Performance and Capacity Planning Best Practices Building Dynamic Applications with the SharePoint Client Object Model Articles by Eric Shupps eshupps The SharePoint Cowboy Eric Shupps' Ten Steps to Optimize SharePoint Performance Webcasts by Eric Shupps eshupps The SharePoint Cowboy Secrets of SharePoint Part 5: Configuring Microsoft Office SharePoint Server 2007 for Optimal Performance Creating End User SharePoint Solutions for Performance and Scalability SharePoint 2010 Performance Enhancements for Administrators by Eric Shupps Microsoft SharePoint Server 2010 for the ASP.NET Developer Eric Shupps on Following Best Practices and Avoiding Common Errors with Microsoft Office SharePoint Server 2007 Development Eric Shupps - SharePoint Performance and Capacity Planning Essentials Troubleshooting Common Performance Problems in SharePoint 2010 Videos by Eric Shupps eshupps The SharePoint Cowboy Channel 9 Interview with Eric Shupps SharePoint TechTalk with Eric Shupps - Different Views on Social Computing SharePoint Post-Deployment Planning and Management with Eric Shupps SmartTrack for SharePoint Feature Overview SmartTrack for SharePoint Podcasts by Eric Shupps eshupps The SharePoint Cowboy SharePoint Pod Show - Design for Performance (Eric Shupps) SharePoint Pod Show - Test Driven Development with Andrew Woodward and Eric Shupps eshupps The SharePoint Cowboy Run As Radio - Eric Shupps Improves SharePoint Performance
SmartTrack for SharePoint Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave

 
​The SharePoint Cowboy


photo of  Eric Shupps
BinaryWave
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA
Eric Shupps and Eric Alan Shupps with BinaryWave the BinaryWave Inc in BinaryWave Incorporated around SmartTrack beside SharePoint Monitoring through SharePoint alongside SharePoint Monitoring visiting @eshupps via eshupps near SharePoint performance and SharePoint management. The SharePoint cowboy eshupps BinaryWave and more on Operational Intelligence via Eric Alan Shupps SharePoint blog. SharePoint monitoring is a hot topic along with SharePoint Performance Measurement and SharePoint tips and tricks from Eric Shupps for SmartTrack. Another Eric Shupps on Technology and Eric Shupps on SharePoint with a new SharePoint Post from Eric Shupps. New BinaryWave post through BinaryWave Inc. and with another SharePoint blog we get to Eric Alan Shupps Blog about SharePoint development. That's Eric Shupps - BinaryWave or Eric Alan Shupps Fort Worth Grapevine Texas Dallas of BinaryWave talking about BinaryWave Operational Intelligence at the SharePoint Cowboy blog and on twitter as @eshupps. Of course SharePoint Administration is on topic for eshupps and another great post from Eric Shupps regarding BinaryWave SharePoint and SharePoint Maintenance.
April 20
Designing Custom Development Solutions for SharePoint 2010

With the inclusion of new tools and features in Visual Studio 2010 which directly support SharePoint development, programmers now have a much wider set of options for creating custom solutions. As with the introduction of any new approach, there are various factors which need to be considered in order to ensure that the final outcome meets the specified requirements and that all of the available functions are fully understood before embarking on a new project. The following article discusses the process of designing solutions in Visual Studio 2010 for SharePoint development, highlights several new features and techniques, and provides an overview of the various options developers should consider during project planning.

SharePoint Solutions, Projects, and Project Items

Visual Studio 2010 introduced the first native correlation between the IDE and the SharePoint framework. Included out of the box are a number of SharePoint-specific project and item types, along with capabilities for automated packaging and deployment of SharePoint solutions. At the most basic level, a SharePoint solution is no different than any other Visual Studio solution – it is simply a container for one or more projects; however, SharePoint projects are a bit more specialized. Each SharePoint project contains, at a minimum, those artifacts necessary to package and deploy the project – primarily a package which defines and creates the WSP that will be deployed to the server.

Each project may contain one or more SharePoint Project Items (SPI's), which are distinct components such as a web parts, event receivers, workflows or other SharePoint-specific artifacts. A SPI may also be somewhat generic, as in a Module which deploys a document to a library or a mapped folder which deploys files to the file system. A project may contain multiple SPI's; however, depending upon the type of SPI's employed, each one may have different packaging and deployment requirements. Some may have different implementation scopes (Site vs. Web, Web vs. Farm, etc.) and others may be incompatible based on target deployment type (Sandbox vs. Farm). When creating a solution design, it is important to determine in advance how SPI's will be grouped together and deployed.

Features

A logical boundary for solution design is the deployment scope of the requisite Features. By default, Visual Studio will group all SPI's with the same scope into a single Feature; however, this behavior may not reflect the manner in which the developer desires the project to be deployed. For example, consider a solution which calls for the deployment of site columns, content types and custom web parts. Since these artifacts are all deployed at the same scope (Site), they could logically be grouped together into a single Feature; however, in some cases this may not be desirable. From a maintenance perspective, it doesn't make much sense to upgrade site columns and content types when adding functionality to web part assemblies or files. From an administrative point of view, columns and content types are often considered Publishing elements while web parts are more likely to be confined to collaboration/team scenarios.

Figure 1 – Grouping Artifacts by Scope

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack


An alternate approach is to group artifacts and Features which serve a particular purpose into a single project. Publishing projects, for example, often include artifacts which span several scopes. For implementation purposes, these collectively operate as an integrated unit and often contain inherent or explicit dependencies (content types depend upon site columns, layout pages depend upon content types, etc.). The same holds true for Site Definitions, which contain artifacts which span all available scopes. Such solutions are typically upgraded and maintained as a cohesive unit.

Figure 2 – Grouping Artifacts by Purpose

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

 

NOTE: Aside from Content Types, Visual Studio 2010 does not include any Publishing artifacts by default (such as Layout Pages, Master Pages or Site Columns). These must be created manually using a Module element.

 

Packages

A package is comprised of all the components required for deployment of a solution (.wsp file) into SharePoint – features, assemblies, images, XML files, ASPX pages, style sheets, user controls, and so on. Once a manual process which involved editing manifest.xml and .ddf files, Visual Studio 2010 now automatically locates elements within a solution and adds them to the package. Using a visual design surface, developers can add or remove solution elements from the package to create a deployable solution that meets their requirements.

Figure 3 - The Visual Studio 2010 Package Explorer

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack


There are also advanced packaging options which allow for the inclusion of additional assemblies, specification of safe control entries, and control over the deployment target (global assembly cache or web application). Behind the scenes, Visual Studio still generates a manifest xml file, to which additional entries can be added or, should more direct control be required, the visual designer can be circumvented and the manifest edited directly (note, however, that once this has been done the visual designer is no longer available for that project).

Figure 4 – Package Manifest Editor

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

 

NOTE: When pressing F5 to initiate the build, packaging and deployment routines, only the project set as startup will be packaged; however, multiple projects may be marked as startup in a solution.

 

Visual Studio makes certain assumptions about how packages should be organized, such as putting everything in the current project into a single package, which may not fit individual design objectives. While each package may be adjusted as necessary, there can only be one package per project, which limits flexibility within a single project scope. While it may be desirable to have one package for web parts and another for list definitions, if these artifacts exist within the same project (perhaps because the same developer works on both or because the web parts depend upon the lists) then by default they will be placed into the same project.

In order to overcome this default behavior, it is not uncommon to see solutions which contain a separate project for each type of artifact, i.e. Contoso.WebParts and Contoso.Lists. While this is certainly a viable design methodology, it can often lead to project proliferation and create clutter in the farm solution store. One potential solution to this problem is to group artifacts by purpose or scope and create separate projects for packaging. For example, consider a project which contains mostly collaborative artifacts (web parts, list definitions, even receivers, etc.) and supporting utility assemblies. These may be grouped together into a single project for development, but packaged separately into, say, Contoso.Collaboration and Contoso.Utilities. In this fashion, the package containing supporting assemblies, such as data access or object classes, could be updated independently of the actual SharePoint artifacts.

Figure 5 – Base Project

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

In this simple scenario, the base project contains all the elements that will eventually be deployed; however, no features or packages are defined within the project itself. Instead, packaging is handled by two additional projects – one for collaborative elements and one for utilities.

Figure 6 – Collaboration Project

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

Within the collaboration project, new features are created for the SharePoint elements in the base project. Visual Studio keeps track of the available elements within the solution and makes them available for inclusion within feature packages even though the features and elements exist in two separate projects.

Figure 7 – Collaboration Features

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack


By default, Visual Studio organizes features based on scope. When creating the Lists feature, only the list definition and list instance are available for inclusion as the scope for these artifacts is Web; however, the WebParts feature displays both the web part and list elements when the scope is changed to Site. Although these can be deployed together in a site-scoped feature, list definitions and instances are actually activated at the web level. It is important to understand the role scoping plays when artifacts are deployed – a site administrator will not have the option to activate a specific feature at the web level if it is scoped at the site level – the feature will only appear in Site Collection Features. If granular feature activation is required (and it often is) then the features should be designed accordingly.

The collaboration project will contain a package for deployment of the required features. The packaging explorer will automatically identify the features in the project and include them in the project package; if necessary, the package manifest can be edited manually to include any additional elements.

Figure 8 – Collaboration Package

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack


It is worth noting that in this example the dependent classes (DataAccess.cs and ListItem.cs) will be included by extension in the package as they exist within the base Contoso.SP2010 project when it is built and compiled (a safe control entry will also be included automatically). The purpose of the Utilities project, which would normally contain all non-SPI artifacts, is simply to allow for solution modifications and upgrades to the base assembly without the need to update the Collaboration package. Admittedly, this is a contrived example, but it serves to illustrate how various components can be extracted into separate packaging projects while all actual development work is performed in the base project. Note also that no features are required in this package as its only purpose is to deploy the base assembly.

Figure 9 – Utilities Project and Package

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack


Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack
 

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack


In this scenario, it will be necessary to package both the Collaboration and Utility projects prior to deployment. Visual Studio allows for multiple projects to be set as startup by modifying the project properties of the solution. First, select the base solution then select Projects > Properties from the VS menu. This will open the Property Pages dialog where the additional packaging projects can be set to startup. This will allow both projects to be packaged when F5 is pressed to initiation the build, package and deployment processes.

Figure 10 – Setting Multiple Startup Projects

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

 

Multi-Faceted Solutions

There are many ways to package and deploy solutions which contain numerous artifacts. It is common to have a single solution in which multiple projects and packages exist which all serve a related purpose. By way of an additional example that reflects a real-world scenario, consider a solution for a public-facing publishing site. Following the "grouping by purpose" methodology, this solution has two main areas – the artifacts necessary for the publishing infrastructure (master pages, layout pages, content types, site columns, images, styles, and so on) and programmatic elements which provide specific pieces of functionality (in this case, web parts). The solution therefore contains two projects – one for publishing and one for web parts. They are packaged and deployed separately, allowing for ongoing maintenance and updates in one area which do not affect elements in the other area.

Figure 11 – Publishing Site Solution with Multiple Projects

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave SmartTrack

This solution could be further broken down with additional projects for core elements – such as a Pages project for master and layout pages, a ContentTypes project for the content types and site columns, and so forth. These projects could be collectively packaged in a separate project created just for that purpose. This is often the case in situations where developers on a team have specific task assignments (one creates the pages, one creates the content types, etc.).

Conclusion

Visual Studio 2010 provides SharePoint developers with a rich set of tools for designing, packaging and deploying solution artifacts. Although the tools do a good job of automatically grouping elements together and creating the requisite deployment packages, the default organizational schema does not always reflect the desires of the developer or ongoing maintenance requirements. Team leads should give careful consideration to which methodology they will use and how the underlying collection of projects supports their decisions. There is no best practice or prescriptive guidance which determines how this will be done – each situation is different; the tools provide the capabilities to create solution structures which reflect the individual working environment and needs of the organization.

Comments

Thanks a lot for such a good post

Hi,

Thanks a lot for such a good post on custom  development.
Appreciated..... :)

To know more about the sharepoint 2010 or MOSS 2007 please visit  the link below::

http://www.tutorialsdirect.com


 on 7/13/2011 10:34 PM

Nice!

I wanted to thank you for this great article.I enjoyed every little bit part of it and I will be waiting for the new updates. This blog has given me opportunity to learn many things regarding products and services. 
http://www.fprinting.com/cheap-bumper-sticker-printing/
 on 7/14/2011 10:49 AM

Great post Cowboy! :-)

Eric, this is a very informative post that really shows the flexibility of the tools, thanks for getting the word out!

Mike Morton
Senior Program Manager
Visual Studio SharePoint Developer Tools
 on 7/20/2011 5:33 AM

Good subject and coverage

Eric,
This type of SharePoint Development Project detail and the value of your experienced perpective on it is a very valuable thing for you to share with the community.
Thanks for taking the time to think out the project structures and make the visuals that really help this post sink in.
Tom Resing
http://twitter.com/resing
 on 7/21/2011 1:39 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Comment Date *

Select a date from the calendar.
Enter the current date to prevent automated spambot comments.

Spam Prevention *


How many letters, not including spaces, does it take to spell "SharePoint Cowboy"?

Attachments

 
photo of Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave Eric Shupps
BinaryWave
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA

 
 
 
Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave 

Eric Shupps LinkedIn Eric Shupps Twitter Eric Shupps Facebook Eric Shupps Google+
 
 

 


 


BinaryWave Eric Shupps eshupps The SharePoint Cowboy SharePoint monitoring SharePoint monitoring tool SharePoint metrics SharePoint administratrion SharePoint monitoring best practices SharePoint management SharePoint management tool SharePoint operations SharePoint operationsmanagement SharePoint administration SharePoint administration tool SharePoint SLA SharePoint service level agreement SharePoint operational intelligence SharePoint performance SharePoint performance monitoring SharePoint analytics SharePoint real-time SharePoint intelligence SharePoint ITIL SharePoint service operations SharePoint uptime SharePoint alerts SharePoint health SharePoint tools SharePoint metrics SharePoint diagnostics SharePoint SmartTrack SmartTrack Operational Intelligence


Copyright © 2013 BinaryWave, Inc. All rights reserved.
This site is brought to you by BinaryWave in cooperation with Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy. We hope you enjoy the SharePoint-related content on topics such as performance, monitoring, administration, operations, support, business intelligence and more for SharePoint 2010, SharePoint 2013 and Office 365 created by Eric Shupps The SharePoint Cowboy. We also hope you will visit our product pages to learn more about SmartTrack, Operational Analytics for SharePoint, SharePoint monitoring, and SharePoint administration, while also discovering great offers from our partners. Please visit the blog of Eric Alan Shupps, Twitter handle @eshupps, for more information on application development, the SharePoint community, SharePoint performance, and general technology topics. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational support solutions for SharePoint. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. He is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.binarywave.com/blogs/eshupps.