devxlogo

SharePoint 2007 and the Thin .NET 3.5 Development Model

SharePoint 2007 and the Thin .NET 3.5 Development Model

hile flying back home over the Atlantic, I thought about how much better developing for 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.

This article provides a brief introduction to the specific improvements that .NET 3.5 brings to the SharePoint 2007 platform, and how those have improved my development life.

I was just one of 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

SharePoint 2007 won’t support WCF out of the box.

SharePoint 2007 doesn’t support WCF out of the box, and as of the writing of this article, Microsoft hasn’t introduced official support for WCF in SharePoint, either. But often, the true beauty of Microsoft products lies in their extensibility. Using a combination of a custom VirtualPathProvider and an HttpModule, you can easily add WCF support to any SharePoint web site (see more information here).

Alternatively, you can simply download the Winsmarts.WCFSupport feature. This is a web-site-level feature that you can activate on any web site, and voila?you have WCF support?just that simply!

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. But with WCF, you have the ability to encapsulate logic in a true SOA form, and then expose and consume it using various technologies, including thick clients, ASPX code behind, Silverlight clients, or even?believe it or not?JavaScript. This is the thin .NET 3.5 development model, which greatly increases your productivity. But applying it to SharePoint greatly increases productivity, code reliability, and the quality of your development experience.

The Old SharePoint 2007 Development Story
Let me make my case with an example. Suppose you wanted to author an ASPX, and put it in the layouts folder; otherwise known as an Application Page.

What are your choices?
You could author the page using an ASPX and a code-behind class. You 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 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 contains exactly what your page needs and absolutely no more. (And you know what “Trial and Error” means: That if hackers try hard enough, they will expose an error.)

So, putting the DLL in the bin directory isn’t such a great choice. You could put the code-behind DLL in the GAC. But to develop such a DLL, you would have to develop on a machine that had SharePoint running, and debug a GAC DLL inside the SharePoint context. To do that, you’d attach to the w3wp.exe process, but then you have the problem of knowing whether the DLL you compiled is the same version that exists in SharePoint, and whether it’s the same version that IIS is using. You have to do some work to discover why your breakpoints aren’t getting hit, and why the SharePoint context seems to time out so mysteriously.

Okay, so code-behind in either DLLs or the GAC isn’t an ideal choice. You could use inline code in the ASPX file. 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 see all your code, and IntelliSense in ASPX files sometimes goes for a walk.

These problems, while not insurmountable, are exactly the types of problems that make development tough. So far, you have three choices, none of which are good. What should a SharePoint developer do? Simple?embrace the thin .NET 3.5 development model.

Editor’s Note: This article was first published in the November/December 2008 issue of CoDe Magazine, and is reprinted here by permission.

The New .NET 3.5 SharePoint Development Story
The thin .NET 3.5 development story lets you treat SharePoint 2007 as a true application platform. Rather than developing code inside SharePoint 2007, you develop it externally?as libraries, which are easier to test and debug. This external development method also lets you deploy functionality incrementally, as you write the WCF back end, or the Silverlight, AJAX, JavaScript, or some other front end. Again, here’s an example.

The thin .NET 3.5 development model greatly increases your productivity.

Suppose you have a SharePoint site with a number of song titles loaded in a custom content type. Now, you could easily create a custom search scope to limit the results to that custom content type. You can view an example of running search programmatically on SharePoint 2007 here. You can then easily craft up the search functionality as a WCF endpoint and deploy it cleanly as a solution, as shown here.

After your WCF service is deployed and available as a part of the SharePoint platform, you can then use it in multiple front ends. I will discuss three here, but trust me; there are many, many other possibilities. But these three should get you excited enough?for now!

Using WCF in Silverlight

?
Figure 1. Custom Silverlight Application in SharePoint: Here’s an example that shows a custom Silverlight application running in a SharePoint page.

Your WCF application can be consumed directly inside a Silverlight application. You can create a WCF proxy for a WCF service that uses basicHttpBinding in Silverlight as demonstrated here. Then you can deploy a Silverlight .XAP application to a document library using the tag in CAML, and download it in a Silverlight-enabled SharePoint web site. Figure 1 illustrates a simple Silverlight application running inside SharePoint that queries song data using a WCF endpoint exposed on basicHttpBinding.

Using WCF with AJAX
After you’ve written and deployed your service library, and assuming that you decorated it by its own namespace, you can simply expose an endpoint that uses webHttpBinding and an endpoint behavior called enableWebScript. This allows the WCF runtime to expose your C# or VB WCF service functionality through automatically-generated JavaScript.

For example, if your WCF contract looked like this:

   [ServiceContract(Namespace = "Winsmarts")]   public interface ISongQuery   {     [OperationContract]     [WebGet]     List GetSongs(string containsText);   }

You could expose the service’s functionality in JavaScript as shown below:

   function GetResults()   {     var resultsDiv = $get("results");     resultsDiv.innerHTML = "Fetching results .. ";     var proxy = new Winsmarts.ISongQuery();     proxy.GetSongs($get("containsText").value,        onSuccess, onFail);   }

As the preceding code shows, the namespace becomes a JavaScript namespace, and then you can simply instantiate a proxy inside JavaScript.

To use the code, you add a ScriptReference to the WCF endpoint, shown below:

                           

Just like all AJAX-enabled endpoints, the preceding code requires you to host the WCF endpoint in the same domain as the JavaScript code.

Using WCF with the AJAX Control Toolkit
The AJAX Control Toolkit is a wonderful set of controls. You can view the toolkit running here. The good news is that with WCF, it’s quite easy to use all these tools inside SharePoint. All you have to do is create a WCF service reference that looks similar to the one shown below:

   [ServiceContract(Namespace = "winsmarts")]   [AspNetCompatibilityRequirements(RequirementsMode =         AspNetCompatibilityRequirementsMode.Allowed)]   public class WCFEndPointClass   {      [OperationContract]      public string[] WCFQueryMethod(         string prefixText, int count)      {         // Implementation goes here      }   }

Expose the service reference over a WCF endpoint that uses webHttpBinding and the endpoint behavior enableWebScript. After doing that, you can use any of the Ajax Control Toolkit controls. For example, the following code uses the AutoCompleteExtender control:

                

You can see an example of the AutoCompleteExtender being used on the NewItem.aspx of a list in Figure 2.

?
Figure 2. Using Ajax Control Toolkit Controls: Here’s an example of using the AutoCompleteExtender control.

Yes, you read that right. The example uses the AutoCompleteExtender inside the autogenerated NewItem.aspx page for a list. The autogenerated page is usually a pain to customize. You can do some limited customization through the SharePoint designer, but how exactly do you get rich functionality as shown above? Do you use InfoPath Forms and craft a custom content type that insists on using those custom forms?

First of all, InfoPath 2007 browser-based forms don’t give you AJAX Control Toolkit-like features. InfoPath, while quite powerful and useful, isn’t known for its easy extensibility when it comes to its controls, and frankly, the above solution just works better.

Wrapping Up
I have discovered the light. If there was anything wrong with SharePoint 2007, it was the unwieldy development experience. You had to:

  • Work on a machine that had SharePoint installed.
  • Debug frequently inside the SharePoint context.
  • Attach and detach w3wp.exe frequently, and if you detached the wrong one, even when you did attach to the correct one, breakpoints would mysteriously not get hit, because the DLL in the GAC was different from the DLL that IIS was using, which was different from the newly-compiled DLL.

Moreover, developers typically did all this inside a virtualized environment which, half the time, involved either staring at frozen Visual Studio instances or at the SharePoint spinner.

You’ll find that the thin .NET development model fixes all these problems. You’ve seen only a brief introduction and a couple of examples so far, but you’ll see more in three subsequent articles, which take each of the scenarios described here, and explain, in depth, exactly how to implement them.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist