Deploying Everything in SharePoint
Let me make this section really simple. You should deploy everything as a solution, and the easiest way to create solutions is WSPBuilder. Here are the high-level portions to deploy:
|Figure 3. Solution Structure: The figure shows the files in the deployable Silverlight + WCF solution.|
- The WCF service deployed as a part of the solution as described here. Note that in this case the WCF Service will need to run under the ASP.NET compatibility mode.
- The same solution also deploys the .xap file in a document library using the <Module> tag in the relevant elements.xml. You could also deploy the .xap as a physical file if you wish.
- Finally, the same solution also deploys an application page, and creates a custom action menu item for it.
In short, the class library from which WSPBuilder creates a solution looks like Figure 3
When you activate the feature, and browse to the application page, you'll see a Silverlight application running in the browser, with full access to the SharePoint context, under my (the currently logged in user) security context, in a nice looking UI (see Figure 4).
|Figure 4. Silverlight in SharePoint: Here's the sample Silverlight application running inside SharePoint.|
Although this example shows the Silverlight application running in a SharePoint application page, it could just as easily run inside a Web Part, or anything else.
And there you have it, folks. This article demonstrated how the thin .NET 3.5 development model simplifies SharePoint development, making the platform more appealing than ever. The bulk of this project was developed outside of SharePoint, and incrementally deployed to SharePoint as it was completed. This has the following significant advantages:
- A better development experience. I did most of the difficult development outside of the virtual machine that runs SharePoint on a Vista OS.
- Leverage talent. You have the ability to scale out and leverage different skill sets in your team, rather than finding one superhero who is an expert at Silverlight, SharePoint, WCF and more—and is available at a reasonable price.
- Modular code. The developed code is modular. The SOA-based architecture ensures that this application doesn't affect any others.
- Supports good development practices.This model lets you follow solid development practices, such as effective source control and effective unit testing.
- Maintainable results. Finally, and perhaps most important, crafting a modular solution means your product requires less effort to write and is more maintainable. When was the last time you both these advantages together?
My next article raises the bar by demonstrating how the thin .NET 3.5 development model helps you author rich HTML UIs, using concepts such as AJAX. Of course, the underlying theme is still developer productivity and maintainable code, working within the SharePoint 2007 platform.