Jason Huh’s SharePoint blog

Sometimes you need to create a WCF service to provide a SharePoint functionality to a remote client. However, hosting a WCF service in a SharePoint box does not look so easy. At least, there are two options — one is to create a custom VirtualPathProvider and the other is to deploy it as a separate web site. Which way to go depends on an IT governance policy, stakeholders, etc., but my quick recommendation is to go with a 2nd option of deploying it as a separate web site.

First, let’s see why you need to create a custom WCF service at all. The out-of-box SharePoint web services under the _vti_bin folder are quite limited in terms of the available functions and power. For example, you really cannot leverage the OOB SharePoint web service to upload a document remotely with a check-in and check-out functionality. Also, in many cases, the OOB SharePoint web services are too granular (or too chatty) to be used as a true SOA service. You will need to consider creating a custom web service, or better, a custom WCF service which will utilizes the SharePoint APIs rather than the OOB SharePoint web services.

So, you created a WCF service, and now need to think about where you will expose the endpoint of your WCF services. Unfortunately, the current version of SharePoint, WSS 3.0 and MOSS 2007, does not support the hosting of WCF services right out-of-the-box. To host a WCF service in a SharePoint environment, you will need to choose from the following two options:

Option 1 - Hosting a WCF service under _layouts folder or under a Virtual Path.

This option requires a hack — you will need to create a VirtualPathProvider and register it to the SharePoint web.config. The following blogs show how to do it.

• Hosting a WCF service in Windows Sharepoint Services v3.0
• SharePoint as a WCF Service
• Winsmarts SharePoint WCF Support 

Even though there is a growing popularity to use this option, I do not recommend this one because this option requires you to create your own VirtualPathProvider (or at least need to use someone’s code) to intercept a WCF service because SharePoint does not handle WCF service files (*.svc) right out of the box. The VirtualPathProvider needs to be deployed to GAC. Also, I found that there is almost no benefit to host a WCF service inside a SharePoint web application since a WCF service really cannot share SPContext, HttpRequest,  Cookies, Sessions, etc. with Asp.net applications effectively (technically, you can if you turn on the Asp.Net compatible mode…, but the mode is turned off by default).

Option 2 - Hosting a WCF service as a separate web site under the same SharePoint farm

This option is really straightforward. You simply host a WCF service as a separate web application on the IIS. Since the WCF service will live in the same SharePoint farm, the WCF service can have a full access to SharePoint APIs.

My recommendation is Option 2.

My recommendation is to deploy your WCF service as a separate web service which requires no custom VirtualPathProvider, no web.config manipulation for registering the custom VirtualPathProvider, and no deployment to GAC.

For those who need to programmatically create a SharePoint calendar view, I posted the full sample code below. Since a Calendar view requires many special fields, the code below will not work against a custom list:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebControls;

namespace CalendarView

{

    class Program

    {

        static void Main(string[] args)

        {

            using (SPSite site = new SPSite(“http://localhost/Site1“))

            using (SPWeb web = site.OpenWeb())

            {

                SPList list = web.Lists["Calendar"];

                SPViewCollection views = list.Views;

                System.Collections.Specialized.StringCollection viewFields = new System.Collections.Specialized.StringCollection();

                viewFields.Add(“EventDate”);

                viewFields.Add(“EndDate”);

                viewFields.Add(“fRecurrence”);

                viewFields.Add(“EventType”);

                viewFields.Add(“Attachments”);

                viewFields.Add(“WorkspaceLink”);

                viewFields.Add(“Title”);

                viewFields.Add(“Location”);

                viewFields.Add(“Description”);

                viewFields.Add(“Workspace”);

                viewFields.Add(“MasterSeriesItemID”);

                viewFields.Add(“fAllDayEvent”);

                string query = @”<Where><DateRangesOverlap><FieldRef Name=”"EventDate”" /><FieldRef Name=”"EndDate”" /><FieldRef Name=”"RecurrenceID”" /><Value Type=”"DateTime”"><Month /></Value></DateRangesOverlap></Where>”;

                SPView view = views.Add(“Calendar View Test”, viewFields, query, 100, false, false, SPViewCollection.SPViewType.Calendar, false);

                view.ViewData = @”<FieldRef Name=”"Title”" Type=”"CalendarMonthTitle”" /><FieldRef Name=”"Title”" Type=”"CalendarWeekTitle”" /><FieldRef Name=”"Location”" Type=”"CalendarWeekLocation”" /><FieldRef Name=”"Title”" Type=”"CalendarDayTitle”" /><FieldRef Name=”"Location”" Type=”"CalendarDayLocation”" />”;

                view.Update();

            }

        }

    }

}

A Thumbnails view is a default view for a SharePoint Picture Library, and SharePoint does not provide an easy way to set a Filmstrip view as a default view. Technically, the All Pictures view is a default view for a Picture Library, and both Thumbnails and Filmstrip are kind of subviews inside the All Picture view. If you examine the behavior of these subviews closely, you will soon find that the subviews are handled from a client side using a JavaScript, javascript:SwitchViewStyle(’filmstrip’) and javascript:SwitchViewStyle(’thumnail’). With these findings, I will describe the steps how to make a Filmstrip a default view of a Picture Library.

Please perform the following steps to make the Filmstrip a default view of a Picture Library:

1. Click Site Actions -> Edit Page.
   

   Click Edit Page to add a webpart

    

2. Click a Add a Web Part button to launch a Add Web Parts dialog box.
   
   
3. Find and Check a Content Editor Web Part and Click OK.
   
   
4. Drag the Content Editor Web Part below the Picture Library Web Part.
5. Click open the tool pane link on the Content Editor Web Part
6. On the Content Editor section, click the Source Editor… button.
7. Type the following javascript inside the Source Editor:
   <script type=”text/javascript”>
   <!–
   SwitchViewStyle(’filmstrip’);
   //–>
   </script>

   

8. Click Save to close the Source Editor.
9. On the Appearance section of the tool pane, set the Chrome Type to None.
   
   
10. Click OK to close the tool pane of the Content.
11. Click Exit Edit Mode link right below the Site Actions.
    

    That's it! Filmstrip is now set to a default view.

     

I tried to create a SharePoint site for contact records with CON as a site name, i.e. http://[server]/sites/CON. A site returned “An unexpected error has occurred.” After contacting Microsoft product support service team, I found out that it is a product issue — You can call it a bug or a feature by design.

This is a response from Microsoft product support service:
“MS-DOS device names are reserved words and cannot be used as folder or file names. When parsing a reference to a file or folder, Windows checks for the case in which a single MS-DOS device name is used in the path, and treats it as invalid.”

The support team also provided this KB article.

The following words are reserved in MS-DOS. You will not be able to use the following words as a sub site name or folder name:

CON, COM1 - COM4, PRN, AUX, LPT1

Microsoft recently released the following article: http://technet.microsoft.com/en-us/library/cc707802.aspx#Section2 It is a sample code acceptance checklist. I think it is a good checklist to start with for assuring the quality of your team’s code. Just like any guidance and checklist, you will need to change the checklist by adding or removing checklist items.