SharePoint 2007 and the Thin .NET 3.5 Development Model

As I am flying back home over the Atlantic, I can’t help but think how much better SharePoint has become after the introduction of .NET 3.5. I have repeatedly insisted that one of the reasons behind SharePoint 2007’s huge success is the application of ASP.NET 2.0 concepts to SharePoint. In this article, I am going to talk about the specific improvements .NET 3.5 has brought to the SharePoint 2007 platform, and how that has made my development life so much better. I will talk of three exemplary examples, and in subsequent articles, I will splice each one of these topics in further depth.

I was one of the many scratching their heads when Soma announced that Indigo, Avalon, etc. would be named .NET 3.5. I’ve said it before, and I’ll say it again. I am convinced that there is a department at Microsoft whose sole job is to give bad names to good products. Count me firmly entrenched in the camp of people who feel .NET 3.5 is a misnomer. .NET 3.5 is based on CLR 2.0, so it is really .NET 2.0 with a whole bunch on top. But, history cannot be rewritten, so we’re stuck with that name.

Since SharePoint 2007 is really built on ASP.NET 2.0, SharePoint 2007 suddenly got a whole lot better with the introduction of .NET 3.5.

WCF in SharePoint

Out of the box SharePoint 2007 won’t support WCF. As of the writing of this article, Microsoft hadn’t introduced official support for WCF in SharePoint either. But the beauty of every Microsoft product is in its extensibility. Using a combination of a custom VirtualPathProvider and an HttpModule, you can easily add WCF support to any SharePoint Web site. You can read details at http://blah.winsmarts.com/2008-5-Super_Easy_way_to_add_WCF_to_SharePoint_2007__wwwcodeplexcom-SPWCFSupport.aspx. Or if you are interested in using WCF, simply go to http://codeplex.com/SPWCFSupport and download the Winsmarts.WCFSupport feature. This feature is a Web site level feature that you can activate on any Web site, and voila!-you have WCF support. It is really that simple!

But what do you get by enabling WCF support?

I am not sure what came first, shrinking IT budgets, crazy deadlines, or the thin .NET 3.5 development model. With WCF, you have the ability to encapsulate logic in a true SOA form, and then expose and consume it in various technologies such as a thick client, ASPX code behind, Silverlight, or even, believe it or not, JavaScript.

This is the thin .NET 3.5 development model, which greatly increases your productivity. But when it is applied to SharePoint, it greatly increases productivity, code reliability, and the quality of your development experience.

The Old SharePoint 2007 Development Story

There are so many things you can develop for SharePoint, but let me make my case by picking an example.

Let’s say, I wished to author an ASPX, and put it in the layouts folder; otherwise known as an Application Page.

What are my choices?

I could author the page with an ASPX and a code-behind class. I could put the code-behind class in the bin directory where the DLL is running under some sort of CAS (code access security) policy that you will have to create. This sounds textbook perfect-until you actually try crafting a CAS policy yourself. It takes a lot of trial and error to come up with a CAS policy that is exactly what your page needs and absolutely no more. And you know what “Trial and Error” means? It means that if a hacker tries hard enough, he will expose an error.

I guess putting the DLL in the bin directory isn’t such a great choice! You could put the code-behind DLL in GAC. But in order to develop such a DLL, you would have to develop on a machine that had SharePoint running, and debug a GAC DLL inside SharePoint context. This means, you’d attach to the w3wp.exe process, but then is this DLL you compiled the same version that exists in SharePoint, and is that the same version as what IIS is using? Why aren’t your breakpoints getting hit, and why does the SharePoint context seem to time out so mysteriously?

Okay so code behind in either DLL or GAC isn’t an ideal choice. You could use inline code in your ASPX. Yes I know this isn’t classic ASP, but it stinks terribly of it. Inline C# in an ASPX will require you to deploy C# code in production, makes it difficult to visually look at all your code, and it allegedly has IntelliSense which sometimes goes for a walk.

These problems, while not insurmountable, did make my development tougher-and my hair thinner.

Sounds like the story of my life, I have three choices and all of them suck. What is the SharePoint developer to do?

Simple-embrace the thin .NET 3.5 development model.

By: Sahil Malik

Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant, and trainer, and a well-rounded overweight geek. He has a passion for SharePoint, data access, and application architecture.

Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to get very highly charged, fast moving, and highly interactive.

You should check out his blog at http://blah.winsmarts.com

sahilmalik@gmail.com