In some ways SharePoint 2007 was a brand new incarnation of the SharePoint product. For the very first time, ASP.NET 2.0 was applied properly to the product. Things such as master pages, membership providers, sitemap providers etc. were used heavily in SharePoint. As a result, SharePoint 2007 got a whole new developer story to it. But in some ways it was a first version of a big product, so the development story left us wanting for more. Wanting for more because in some ways the API wasn’t ideal, and most certainly the development tools were somewhere between non-existent to bad. Diagnosing SharePoint errors was another frustrating story many have endured. What has changed in SharePoint 2010? Let’s find out.
Much better development tools
Developing for SharePoint 2007 meant either handcrafting your own project structures, or having community products such as WSPBuilder greatly help you out, or use tools released by Microsoft such as VSeWSS. It is fair to mention that VSeWSS was released very late in the product cycle. The whole world was already using WSPBuilder. But one very good reason for picking VSeWSS over WSPBuilder was the possibility being able to the current version of tools built into Visual Studio 2010.
I am very happy to say that the Visual Studio 2010 built for SharePoint 2010, actually work! They are actually good. You no longer need any community tools, or visits deep into hackistan to get simple things done. Of course it is important to remember that the Visual Studio 2010 tools are built for SharePoint 2010 only, you can’t use them for SharePoint 2007 platforms. Now, you still need your own SharePoint development machine, but now that machine can be Windows 7 or Windows Vista. Client operating systems are supported for development reasons only. Also, as much as these tools try and wean you away from the 14 hive, now known as SharePoint root, directory structure, believe me, you still need to know it. Not only that, there is still no replacement for basic SharePoint fundamentals, such as what happens when you deploy a WebPart.
For instance, writing a WebPart in the new Visual Studio 2010 tools is a perfect example. Earlier, using WSPBuilder, you had to craft up a directory structure that would literally represent the feature structure in the 12 hive. Then you had to meticulously hand craft the XML inside feature.xml, another set of XML inside your elements.xml, in which you had to remember that you had to deploy a .webpart file using a module into the _catalogs/wp, with a list ID of 113. Then inside of the .webpart file you had to remember to have a certain XML structure so your WebPart would be properly available in the right group, with the right icon and the right name. And then if anything was misspelled, there were usually no errors. Oh and you had to remember the feature had to be scoped to a site collection, which is really referred to as “Site” in the XML. What a mess!
In comparison, Visual Studio 2010 tools let you write an equivalent WebPart using the following steps:
- Create an Empty SharePoint project
- Right click, add a new WebPart.
Or, if you prefer, just create a Visual WebPart Project, though that requires you to write your WebPart as a farm solution in the current toolset. Now, you still have to know the basics – you have to know that a safecontrols entry will be created for you, you have to know that a .webpart file is deployed that you are responsible for the cleanup of, and you have to know the fundamentals of Sandbox solutions vs. Farm Solutions which is a new, and very important concept in SharePoint 2010.
Reworked Architecture – Sandbox Solutions
When you create a SharePoint Project in Visual Studio 2010, you are presented with the following dialogbox:
There are two questions being asked here. The first is, which local site do you want to use for debugging? This is the same machine that you are running SharePoint on. Some may wonder why Visual Studio has to ask such a silly question, because after all this is always your local machine. The reality is, sometimes you may have alternate URLs setup even for your local site, and that may be important in certain development tasks. Secondly, the site collection you intend to debug your code on may not be a root level site collection. Finally, if you have multiple web applications, this tells Visual Studio which w3wp.exe process to attach to for debugging. Providing the URL tells Visual Studio what w3wp.exe to attach to, in order to debug your code. So you see it's not such a silly question after all.
That was my marketing side talking. Although in simplistic scenarios F5 debugging will work, in many situations you will still find yourself attaching to processes. For example, sometimes your code may not run inside w3wp.exe. It may run under a separate EXE called SPUserCodeService.exe. That would be a sandboxed solution which I will cover in more detail later in this chapter, but for now, that is the second question Visual Studio wishes you to answer. Therefore, the second question is whether you intend to create a sandboxed solution or a farm solution? A farm solution is what used to be a solution in SharePoint 2007. It had unfettered rights to your SharePoint farm, so it could do anything. Sounds like a good proposition, but this created an immense headache for the two poor farm administrators in your organization who were then expected to somehow review every line of code being deployed to the server. A task they intend to get around to doing right after they solve world peace and hunger. Frankly, it is unreasonable to expect two overtaxed IT Pro people to review every single developer's code. Plus since some developers can be really crafty with custom code, while being necessary, is the number one reason for support issues on SharePoint in general.
In response, Microsoft came out with the concept of sandboxed solutions, sometimes also referred to as user solutions or user code. Put simply, a sandboxed solution is what runs inside a secure sandbox. It runs inside a separate process from W3WP.exe, and it is protected by a CAS policy, so you no longer have to craft custom CAS policies. Also, in addition to being more secure, it is also more easily monitored. Being more restricted, secure, and being more easily monitored, sandboxed solutions can now be deployed with more confidence. Thus, they are now deployable and can be activated right through the site collection. The Farm Administrator doesn't even need to be bothered, because he is monitoring the solution anyway. You cannot break his farm by deploying a sandbox solution, so everyone can be at peace, no more IT-Developer wars.
If there are two things you carry from this article about Sandbox Solutions, they are:
- Secure by default, you should create sandboxed solutions when you can. Creating a farm solution unnecessarily is bad practice. Perhaps a better way of saying this is, create farm solutions only when you cannot create a sandboxed solution.
- You can choose to change your mind later, i.e., change a sandboxed solution to a farm solution or vice versa if you need to.
Oh and did you hear about the cloud? Microsoft is all about the cloud these days, and so is everyone else. I really doubt you’ll be able to deploy farm solutions on SharePoint online.
Client Side APIs
What are good development tools without a decent API? We live in a changed world, 5 years ago, with no facebook, no google maps, no foursquare, it was actually possible to get lost and avoid people you didn’t like! Now you have all these crazy applications that feel like desktop applications, but they run right through the browser. So, finally, for the very first time in the history of computing, you have the power of desktop apps, with no installation hassle, and complete security! How did we do it?
So the question is, is any of this power available to you? Certainly! It is available to you in 3 forms on the server side.
- The Client Object Model, which gives you a whole new namespace at Microsoft.SharePoint.Client, which looks and feels like a subset of the server side API with two big differences.
- It allows you, the developer to control when you round trip to the server, and what is done during those round trips. Concepts such as concurrency management, object identity are built into its API.
- The REST API, which exposes every SharePoint list over a RESTFUL interface. Which means you can use simple HTTP Verbs such as GET, PUT, MERGE, DELETE, and POST to query and update data on the server, or even generate proxies and use higher constructs such as LINQ to work with server side data.
- Custom WCF services, because both the client object model, and the REST API are built using WCF – you can write your own services if you wanted to.
Better Diagnosis Tools
An “unexpected error has occurred”. Well I guess, I wasn’t expecting an error in the first place, was I? Diagnosing SharePoint errors can be a black art, there are many places to look at when an error happens. This is because the product is inherently big and complex with a lot of moving parts. So I was really excited to see some improvements on the error logging and tracing side. SharePoint’s central logging capability is referred to as ULS, or the Unified Logging Service. The ULS, is a bunch of text files, that wrap around a certain character length, but suffice to say, each file is wide enough that it doesn’t fit properly on a 30” monitor in 8pt font even. Looking for your error inside the ULS can be almost like looking for a needle in a haystack.
Well, not anymore! In SharePoint 2010, you get an error message that looks like this,
Note there is a Correlation ID there? Now using that correlation ID, you can easily trace down your error needle in the ULS haystack. And there are tools available to help you do that. One such tool is the ULS Viewer which you can download for free from code.msdn.microsoft.com/ulsviewer. And guess what, that tool will work with SharePoint 2007 as well. And in general, there are many other such enhancements in the logging framework, and diagnosis of issues in your SharePoint installation.
SharePoint 2010 is quite different from SharePoint 2007. One article is merely touching the tip of the top molecule of the iceberg. Come join us for more such information at the DevWeek SharePoint 2010 post conference on Friday, March 18th, 2011 with Sahil Malik. You can find more details about the post conference workshops here.