SharePoint 2010 Genesis Framework – A framework that will help you create amazingly structured SharePoint solutions

Summary: SharePoint 2010 Genesis Framework is a framework that helps you declare fields, content types, lists and feature definitions through code. It also helps with provisioning and stronly typed data access.

One of SharePoints greatest strengths is its flexibility. Power users can easily create very powerful solution without much involvement of developers. In many cases though, custom development is needed for parts of a solution. In those cases, it’s very important to properly package the code together with the storage structures such as site columns, content types, lists, views and so on into a solution package.

However, doing this the “classic” way – defining the storage elements with CAML can cause some challenges both during the development phase and when the solution goes to application management. Most developers struggle with the following challenges:

• A lot of CAML/XML needs to be written
• It’s difficult to handle additions and changes to content types already in use
• No strongly typed access to SharePoint Data, unless you choose use LINQ-2-SharePoint

The new upgrade actions in SharePoint 2010 helps somewhat, but when working in an agile manner with deployments every 2-3 weeks, the XML can get really messy.

What many developers do is to manage most of the provisioning of content types, site columns, etc. with code and “ensure-style-features” that incrementally update the content types, lists, views, etc. This requires quite a lot of coding though, and many developers create their own helper classes that quickly evolve into “mini-frameworks”.

Tony Restaino, a senior SharePoint developer at Avega has been working on this issue for a while and have recently released an extensive framework to solve this issue – SharePoint 2010 Genesis Framework (SPGEN).

Tony and I have been working for a client on a two large SharePoint projects for a while now, and we have been using this framework to define content types, site columns, features, etc. and all the provisioning and data access. Want to add a new field to a content type? No problem – just create the field as a class, add it to the content type, rebuild and deploy the code, reactivate the feature and it’s there! The framework has also helped us implementing the repositories with with strongly typed data access in no time!

It’s just amazing how easy life gets with solutions like these! If only Microsoft could be just as thoughtful as Tony when developing the SharePoint API 🙂

A few of the key features of SPGEN:

• It allows you to create classes that represent the different kind of elements in SharePoint – Site Columns, Content Types, List Instances, Views, Features etc.
• You set attributes on the classes that correspond to the attributes of the SharePoint XML elements. This gives you strongly typed access to the definitions at any time!
• The framework provides a lot of helper methods to provision fields, lists, views, etc. It automatically takes care of incremental updates, such as adding a new field to a list.
• It also provides a way to easily create ListItem–object field mappers that maps list items to any class – no need to use the nasty auto generated mega classes from SPMetal!  You can even create your custom field adapters if you have custom columns that maps to complex data types.
• It provides data access methods that allows you to do both CAML and LINQ queries against the lists, and returns the result as strongly typed objects.
• It provides a LINQ implementation that has a LOT better performance the LINQ-2-SharePoint (at least according to our own measurements).

As you can see, it’s a very competent framework that can save a you lot of work – especially when developing custom code-based solutions. I strongly encourage everyone to check it out and give it a try!

Read more and download the framework here:

http://spgenesis.codeplex.com/

Configuration Management with Sandboxed Solutions

In our current project, we’re just about to introduce our first sandboxed solution into our SharePoint farms. This raises some interesting questions regarding how this fits into our existing configuration management process.

Until recently, we only had full trust solutions in our farms. Do deploy these, we go through a pretty straightforward change management process: The build server builds the solution packages, labels the code and assigns the version number to the WSP name. Developers can then deploy the packages to the integration environments, to which they have full access as administrators. When the packages are ready for testing, developers sends a request to Configuration Management (CM) to deploy certain packages to the test environment. CM then contacts operations, who perform the deployment. When user acceptance testing is completed, the packages are deployed to production.

This process works very well for full trust solutions. But how do things change when we start introducing sandboxed solutions? It’s not obvious at first how these fit into the established configuration management process.

If the user code service is enabled, sandboxed solutions can be deployed to any site collection without involvement of the farm administrator. It’s considered safe to do so because the code runs in an isolated process, and because the resource usage is monitored and limited. Does this mean that should be free for all site collection administrators to install whatever solutions they want on their sites?

The answer is, of course, no. The sandbox is just an execution model that affects the maintainability and the level of isolation the code runs in. However, from a configuration management point of view, sandboxed solutions are no different than full trust solutions.

Sure, the sandboxed solution can’t compromise the overall stability and performance of the farm, but it can still mess up the site collection it runs in. If the code you write provides features that are business critical for the end users (or might become in the future), it doesn’t matter if you run it in a sandbox or not. If you want predictable results, you still need to test your solution in a production-like test environment. And of course, you still need to keep track of exactly which version is deployed to each environment.

So, we decided to apply the same CM process to all solutions – sandboxed or not. The only difference is that operations doesn’t need to perform the deployment, site collection admins can do that themselves after getting approval from CM. And of course, all packages must go to the test environment first to ensure everything works as expected before deploying to the production environment.