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
|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
For example, if your WCF contract looked like this:
[ServiceContract(Namespace = "Winsmarts")]
public interface ISongQuery
List<BO.Song> GetSongs(string containsText);
var resultsDiv = $get("results");
resultsDiv.innerHTML = "Fetching results .. ";
var proxy = new Winsmarts.ISongQuery();
To use the code, you add a ScriptReference
to the WCF endpoint, shown below:
<asp:ScriptManager ID="ScriptManager1" runat="server">
<asp:ServiceReference Path="SongService.svc" />
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")]
public class WCFEndPointClass
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:
ID="ToolkitScriptManager1" runat="server" />
<asp:TextBox ID="prefixText" runat="server" Width="280"/>
... other properties>
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.
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.