Random Thoughts of a Scatterbrain.
 Tuesday, May 06, 2008

SharePoint "Unknown Error" Quirk

5/6/2008 3:16:53 PM (Eastern Daylight Time, UTC-04:00)

Anyone who's done any bit of SharePoint development is probably familiar with the completely useless "Unknown Error" view.  Well, in fact, SharePoint actually knows what the error is, it just doesn't want to tell you (okay, it's really just disabled for users).

In ASP.NET, you can usually get error messages to show up by setting <customErrors="Off"/>

However, this is not sufficient with SharePoint. As Stefan Keir Gordan points out, to get the nitty gritty details, you also need to set <SafeMode CallStack="True""/>

 Thursday, April 24, 2008

Nuking SharePoint Styles For Layout Page Applications

4/24/2008 8:59:46 AM (Eastern Daylight Time, UTC-04:00)

SharePonit layout apps (as I call them) are the missing link in most developer's understanding of SharePoint and why it seems like it can be a pain in the butt as a development platform.  As I've discussed previously, SharePoint development only deviates from regular ASP.NET development ever so slightly.  A bit of creativity and ingenuity easily overcomes most hurdles.

As I'm doing development in the area, I'd like to help shed some light on the mystery of it all and show how developers and SharePoint can work together in harmony :-)

One of the first steps to making happy with SharePoint when working with layout pages is to nuke the SharePoint CSS which creates weird padding around the main work area.  I'm sure it may have some purpose, but it's irrelevant for us at the moment.

Let's take a look.

In the following screen, I've added a <div/> element with a one pixel, black border with width and height set to 100% (this is in IE7 and it looks about the same in FF2).

Notice the fat white padding on the top and the right.  This is useless and ugly.  Not only that, we didn't acheive the 100% height that we'd like to.  We can nuke it with some CSS:

/*--- override WSS styles ---*/
body { height: 100%; }
.ms-formareaframe { padding: 2px 4px 4px 4px; background: #fff; height:100%; }
.ms-propertysheet { height: 100%; }
#onetidMainBodyPadding { height: 0px; }
#onetidMainBodyPadding img { height: 0px; display: none; }
#onetidYPadding { width: 0px; }
#onetidYPadding img { width: 0px; display: none; }

And here's the result:

Bingo!  It looks kind of the same in FF2 (FF2 overdraws the 100% declaration and cuts off the bottom and right borders; this does require some CSS hackery to fix).

But the big picture is that now we have a blank slate with which to integrate with SharePoint.  You get all of the benefits of SharePoint authentication, document management, profiling, and so on just by putting your ASP.NET application into SharePoint as a layout page.  Development is easier than it would seem since the package, during development, only has to be deployed once.  Otherwise, all of the files can be deployed to SharePoint using an automated XCOPY or manually.  In some cases, for example working with ASPX page layout, the page can be accessed directly via file share (this is how I do all of my layout).

For more info on creating layout apps, check out the following articles on packaging SharePoint solutions:

 Wednesday, April 02, 2008

SharePoint As A Development Platform

4/2/2008 9:19:53 AM (Eastern Daylight Time, UTC-04:00)

I got an email today regarding a blog post by Jeffrey Palermo on the shortcomings of SharePoint as a development platform.

Now I have to say, SharePoint is not without fault (particularly in the area of feature packaging and deployment), but Jeffrey's perceived issues with SharePoint really show either the lack of personal development experience with SharePoint or a lack of creativity on the part of the team he's working with.

Let's get one thing clear first, okay?  SharePoint is meant as an enterprise collaboration and document storage platform, first and foremost.  One must always bear this in mind with regards to any discussion on SharePoint.  Why is it so big?  Why is it clunky in some places?  Why does it have to be installed on a server OS (okay, I admit, this one is probably more about licensing and $$ than anything technical)?

It seems that Jeffrey's major beef, that it must be installed on a server OS, kills any benefits of SharePoint as a development platform immediately.  So let's tackle this one first. 

First, a disclaimer: I'm not a SharePoint guru.  I don't have 5 years of experience with SharePoint.  I'm only going on what I've learned in working with SharePoint, day in and day out, for the last year.

In our development group of 5 or so people, we've managed to develop against SharePoint quite well, despite the fact that we all run XP as our primary development environment.  How?  Virtual machines.  Of course, some would view this as a hassle, as another stumbling block or quite clumsy.  I view it otherwise as there are numerous benefits in developing against a VM server environment:

  1. Every deployment is exactly the same.  This means that server names, file structures, databases, and so on are exactly the same for every developer.  This aids -- not hinders -- the development of automated scripts and deployment utilities.  On our team, we usually synchronize images once every month or so.  What this means is that we'll take turns updating a common image and then everyone will grab a copy of said image.
  2. Virtual Machines are easy to deploy.  It's called: copy-paste!  Nothing easier when adding a new developer to your team.  Instead of configuring a whole new SharePoint environment, just have the developer copy the latest development image.  So easy, a caveman could do it.
  3. Virtual Machines can be rolled back.  Try doing that with your development environment!  If every developer had SharePoint deployed on his or her machine, a mistake (deleting/altering some core database tables or records, for example) would be devastating...it would mean at least a day of lost work time trying to rebuild the development environment.  Using virtual machines to host the server environment protects it from inadvertant dismantling.  And even if it is somehow altered for the worse, no matter, get another copy from someone else!  And of course, being able to rollback the image (provided that you created a snapshot) makes updates (for example, adding a SQL Server service pack) painless.
  4. Virtual Machines are portable.  Why does this matter?  Demos!  There's nothing more convenient than having a sales guy pack up a copy of the VM with all of the software installed and tweaked for demos.  This is a huge bonus.

Look, the suggestion of developing with SharePoint in a "native" environment in a team is just plain stupid; it's a matter of working harder, not smarter and it shows a lack of creativity in terms of development management.  (One disclaimer: some Visual Studio tools from Microsoft for SharePoint cannot be installed on XP...this is a shortcoming, for sure, but it hasn't really affected our development.  If absolutely necessary, you can install a stripped down copy of Visual Studio on the VM).

Now let's address each of the other 7 points that Jeffrey brings up:

  1. SharePoint isn't easy to install.  I'm going to skip that one because clearly, this man has never installed SharePoint.  It's nothing more than point and click...my gosh, I don't understand how it could possibly be easier.  Aside from this, using a VM approach, it only has to be installed once.
  2. SharePoint isn't easy to configure.  See above.
  3. SharePoint does not integrate well with simple tools.  I'm not sure what he means here.  Many administrative tasks can be handled by stsadm.exe which in turn, means that many of the administrative tasks can be handled by batch scripts.  Aside from this, SharePoint is just an average ASP.NET application.  Stopping and starting IIS, xcopy, and so on...these are all still applicable to a SharePoint deployment.
  4. SharePoint isn't easily extended to make simple tools.  What?  Nothing could be further from the truth.  The only beef that I would hold is that Microsoft doesn't package the SharePoint DLLs separately so you have to extract the DLLs from the GAC of your server environment.  But once you do that, it's easy to reference and use the API by copying the DLLs to your development environment.
  5. SharePoint isn't easy to debug.  Again, I'm not sure what the issue here is.  The process of debugging SharePoint applications (web parts, layout pages, etc.) is no harder than debugging any standard, run of the mill ASP.NET web applications.  Okay, sure, you can't just hit F5 (oooh, the horror!), but seriously, I hate F5 developers - sometimes, F5 just isn't the way to go, dude.  I'm also pretty sure chimps (or macros) can be trained to hook up the debugger and hit F10 and F11.  As for debugging core SharePoint, well, I guess he has a point since the source and debugging files aren't available (not that I know of), but I don't see that as an issue.  I mean, how many platforms ship with debugging symbols included?
  6. It's not easy to create test automation for SharePoint.  There is some truth to this since it requires the developer to learn about the platform first (API, database tables, web services, and so on).  But I don't think it's any more difficult or challenging than setting up automated tests against any other third party platform.
  7. SharePoint configuration does not store easily in source control.  See above regarding VMs.  Aside from this, he's got it all wrong again.  We can look at this from a few different angles.  First, SharePoint is just an ASP.NET application.  Repeat that to yourself about 100 times.  With regards to application configuration (in terms of the web.config), it's as simple as copying the web.config to your source control system and using a script to deploy it on build.  Secondly, if we look at the configuration in terms of web parts and layout pages, it's possible to include these in source control as well using solution packages deployed either on build or manually as features.  Certainly requires a bit of research to get it working the first time, but it's not a task that takes more than 1-2 days of experimentation.

From personal experience, I've found SharePoint a very compelling application development platform (again, that's not to say that it doesn't have shortcomings) because it's nothing more than ASP.NET but with the added bonus of a document management/storage API, profiling, permissions, and it acts as an integration platform for a variety of applications. 

You can make it as hard or as easy as you want it to be with regards to developing applications for SharePoint.  It's only a matter of how much time you are willing to put into flipping through the API and understanding the fundamentals of working with SharePoint.  A big part of successfully and painlessly developing against SharePoint is creativity in terms of setting up your development environment and automation (batch scripts, pre/post-build scripts).

The points that Jeffrey, didn't bring up -- the true pain points -- are really "fringe" features so far as I'm concerned.  Namely, this centers around SharePoint hosted and integrated workflows and InfoPath (because no one likes and no one actually uses the otherwise useless and purposeless InfoPath).  You're not required to use InfoPath or SharePoint hosted workflow; in FirstPoint, absent the early documentation and tools required to be productive on this front, we made an early decision to host workflow in our own environment. Sure, we miss out on some of the native features of SharePoint like workflow state visibility and integrated forms via Forms Services, but I don't see it as something we can't overcome as documentation and tool support becomes better on this front.

 Friday, March 28, 2008

SharePoint: The Second Coming Of Lotus Notes?

3/28/2008 8:51:33 AM (Eastern Daylight Time, UTC-04:00)
As I was pondering the suckage of Lotus Notes, I came across an interesting little piece on a CMS Watch Report titled: "SharePoint Has Become the New Lotus Notes":

Microsoft Office SharePoint Server 2007 is repeating history as it mimics the allure and pitfalls of Lotus Notes, according to research released by CMS Watch, an independent analyst firm that evaluates content technologies.

SharePoint exploits traditionally underserved collaboration needs for information workers laboring within Office tools, and fulfills a common desire to easily create disposable workspaces, CMS Watch found.

Like Notes in a previous decade, IT often embraces SharePoint as a simple answer to myriad business information problems.  But the platform can morph into a technical and operational morass, as repositories proliferate, and IT comes to recognize that various custom applications require highly specialized expertise to keep running properly.

...

The SharePoint Report 2008 concludes by advising customers to establish clear boundaries on SharePoint services, to keep it from becoming their new Notes – the platform that everyone loved, but then loved to avoid.

While SharePoint does indeed have it's weaknesses (total lack of any integration with ASP.NET AJAX in the SharePoint implementation itself -- guess we'll just have to wait for 4.0, web services support is still kind of weak) and oddities (CAML?), it's nowhere near the steaming pile that is Lotus Notes.

On a serious note, I do kind of see the point in that last paragraph there.  SharePoint often gets evangelized as some silver bullet for collaboration ("Oh look, workspaces! Workflows! Tasks lists!") but I've never been in an organization that's used SharePoint in a way that was actually of any aid to productivity or collaboration; people just don't seem to want to log onto a corporate SharePoint portal unless they have to. 

That's not to say that the platform doesn't have its useful bits, but the real gem in SharePoint is its integration with Office applications as a platform for "seamless" sharing of documents and I think the idea of offering that to a much larger audience (via Office Live Workspaces) is long overdue from Microsoft.  Until recently, there were few integrated solutions for small businesses, students, and other non-business groups for the very simple act of sharing Office documents aside from using e-mail. 

Even when I joined Zorch Software, I would do a facepalm regularly when I got an email with a document attached with a "v15" suffix.  I'd save it in the same folder as the previous 14 "versions" that I received.  The irony.  The problem is that most of SharePoint just isn't that useful.  Even in a tech minded organization like Zorch Software, you just can't break some people out of old habits; to many, collaboration is synonymous with e-mail.  There is a whole generation that doesn't get wikis and doesn't want to learn wiki markup. 

Well, in any case, I'm still not over the fact that I'm being forced to use Lotus against my will and I'm still bitter over the fact that it's been so hard to get people to embrace our Trac wiki and embrace the ticket system for tracking issues.

 Friday, March 07, 2008

WSS And DateTime Error

3/7/2008 12:16:40 PM (Eastern Standard Time, UTC-05:00)
In working with the SharePoint web services, I've noticed consistent errors with a few of the services which tend to return the following string:
String was not recognized as a valid DateTime
I hadn't been able to figure out what exactly the error was until today.

It's actually not related to a date/time string at all, but rather, the root of the error is in the service implementation itself.  The actual underlying error is an error indicating that a field value is no longer valid.  For example, if the item had a field referring to a lookup list, changes in the target list may invalidate a value on a given item.  Instead of returning a useful error, the web service returns the error above.

You may find this error when using the lists.asmx service or the dspsts.asmx service.

I "fixed" this by removing the offending field from the content type and also from the list and voila, no more errors.

It's hard to track down because the SharePoint itself will render the properties without any error indication in the view and edit properties view, but it will fail the entire request if one field is invalid and return a useless SOAP error.

 Monday, February 25, 2008

SharePoint Layout Pages With CodeBehind And Prototype

2/25/2008 8:11:26 PM (Eastern Standard Time, UTC-05:00)

Let it be known that I hate out of the box ASP.NET.  Hate it, hate it, hate it, hate it.  I detest it.  The simplicity with which it allows the average developer to create applications leads to applications designed for RAD and not for scalability and it does not encourage good decoupling of business logic from UI logic.  Certainly, there are a number of frameworks which aim to alleviate this (the Web Client Software Factory, for example), but I like to take it to another level all together.

Some would argue that I take the separation of UI and application logic to the extreme: my preferred methodology relies almost purely on client side scripts to render UI and using only web services to supply data using ASP.NET AJAX.  Certainly, I lose design time support, but I gain in pure speed (all of the UI logic is in Javascript files which are cached by the client), data transfer sizes (since the only traffic is data, no presentation whatsoever), and the ultimate decoupling of UI development and server component development (the UI developer only needs to know the data model exposed by the web services).

The way I look at it, you'll only write the code a few times, but it could be in use for months (and if you're lucky in this Web 2.0 age, even a year or two).  Sure, you lose some productivity for a single developer with the loss of design time support, but you gain tremendously over time with each request serviced in terms of performance and bytes saved (a particularly important point for high traffic/high data volume applications).  As a bonus, I find it generally easier to think about application design in these terms.

Admittedly, this model seems to work better for "business applications" as opposed to "content applications".

In any case, I was interested to see if this methodology could be applied to SharePoint development as I've been working with SharePoint for quite a while now, but not at the UI level.  SharePoint allows you to deploy "application pages" which can be seemlessly integrated (kind of) into a SharePoint deployment.  This seemed like the perfect starting point to try to integrate ASP.NET AJAX and prototype, one of my favorite Javascript libraries.

The general steps are:

  1. Create an ASP.NET AJAX web application
    1. Add a reference to the Microsoft.SharePoint assembly
    2. Add the prototype.js script file to the project
    3. Add a strong name key file and sign the project
    4. Build a simple page
    5. Create a simple service
  2. Copy the content files (.js, .aspx, .asmx) over to the server to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\ into a new directory.
  3. Test by visiting the URL: http://myserver/_layouts/mynewdirectory/default.aspx

The base page should be simple.  Use the default page created by the ASP.NET AJAX web application project template and change the base class for the _Default.aspx.cs file to LayoutsPageBase instead of of the default of Page.  If you're not using ReSharper ;-), you'll need to add a using statement to your file:

using System;
using Microsoft.SharePoint.WebControls;

namespace WssAjaxApplicationTest {
    public partial class _Default : LayoutsPageBase {
        protected void Page_Load(
            object sender, EventArgs e) {}
    }
}

Next, you will need to modify the Default.aspx file.  The gist of the modifications comes from an MSDN article by Ted Pattison:

<%@ Page Language="C#" 
    AutoEventWireup="true" 
    CodeBehind="Default.aspx.cs" 
    Inherits="WssAjaxApplicationTest._Default" 
    MasterPageFile="~/_layouts/application.master"%>

<asp:Content ID="Main" runat="server" ContentPlaceHolderID="PlaceHolderMain">
    <script type="text/javascript" src="_scr/prototype.js"></script>
    <script type="text/javascript" src="_scr/WssAjaxApplication.js"></script>
    <script type="text/javascript"> 
        var application;
           
        function Init() {
            application = new WssAjaxApplication();
        }
        
        Event.observe(window, "load", Init, false);
    </script>
    <asp:ScriptManager ID="ScriptManager1" runat="server" >
        <Services>
            <asp:ServiceReference Path="~/Services/EchoService.asmx" />
        </Services>
    </asp:ScriptManager>    
    <div>
        <input type="text" id="message-input" />
        <input type="button" id="action-button" value="Go!" />
        <br />
        <div id="message-output"></div>        
    </div>                
</asp:Content>

<asp:Content ID="PageTitle" 
    runat="server" 
    contentplaceholderid="PlaceHolderPageTitle" >
    Echo Page
</asp:Content>

<asp:Content ID="PageTitleInTitleArea" 
    runat="server" 
    contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
    The Echo Page Test
</asp:Content>

I've bolded the key part above, which is linking to the master page for SharePoint layout application pages.  In addition, you can see that I've created three placeholder content sections with the key section being the PlaceHolderMain.  I've placed my Javascript references and my ScriptManager into this section, pointing to our simple service, EchoService.asmx.  Notice the use of the root squiggly "~" :-D and the lack of squiggly on the script references to prototype.js and WssAjaxApplication.js.

The service I'm going to be using for this demo is a simple "echo service" which just echoes the input string with the server timestamp attached.  The following is my simple implementation of this web service:

using System;
using System.ComponentModel;
using System.Web.Script.Services;
using System.Web.Services;

namespace WssAjaxApplicationTest.Services {
    /// <summary>
    /// Summary description for EchoService
    /// </summary>
    [WebService(Namespace = "http://tempuri.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    [ToolboxItem(false)]
    [ScriptService]
    public class EchoService : WebService {
        [WebMethod]
        [ScriptMethod]
        public string Echo(string message) {
            message = string.Format("You said: \"{0}\" at {1}", 
                message, DateTime.Now);

            return message;
        }
    }
}

As you can see by the .aspx page above, I've organized my service in a sub-folder called "Services".  Now just make sure that you've added a copy of prototype.js under the _scr directory and my application script:

WssAjaxApplication = Class.create();

Object.extend(WssAjaxApplication.prototype, {
    initialize:function() {
        this.MessageInput = $("message-input");
        this.ActionButton = $("action-button");
        this.MessageOutput = $("message-output");
        
        Event.observe($('action-button'), "click", 
            this.OnClickActionButton.bindAsEventListener(this), false);
    },
    
    OnClickActionButton:function(e) {
        if(e) { Event.stop(e); } // Stop the event       
        
        // Perform the echo.
        WssAjaxApplicationTest.Services.EchoService.Echo(
            this.MessageInput.value,
            this.OnClickActionButtonSuccess.bindAsEventListener(this),
            this.OnClickActionButtonError.bindAsEventListener(this)
        );          
    },
    
    OnClickActionButtonSuccess:function(result) {
        this.MessageOutput.innerHTML = result;
    },
    
    OnClickActionButtonError:function(error, userContext, methodName) {
        window.alert(methodName + 
            " failed with the message: " + error.get_message());
    }
});

The script simply attachs an event listener to the "Go" button and handles the click event.  Notice how clean and simple the HTML portion of the page is and how clean the Javascript is as well (admittedly, this is a very simple example).  The client rendering is completely decoupled from the UI logic except for the data and operations contract. 

You should be good to go so far as code goes.  Now compile your project with a strong named key file. 

Hopefully, the project was compiled successfully.  The next step is to copy the output dll to the GAC of the SharePoint server.  Be sure to note the public key token value.

This is probably the trickiest part: now you need to carefully merge the configuration files (is there a better tool to do this with?) generated by the project template with the web.config file located at the virtual directory root of your SharePoint application.  For example, if you have an application deployed at port 8080, the web.config file should be located at C:\Inetpub\wwwroot\wss\VirtualDirectories\8080.  Be sure to save a backup copy of the configuration file first before you attempt to merge it!

Once merged, you will need to add one more element to the configuration file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration> 
    <system.web>    
        <compilation batch="false" debug="false">
            <assemblies>
                <add assembly="Microsoft.SharePoint, 
                    Version=12.0.0.0, Culture=neutral, 
                    PublicKeyToken=71e9bce111e9429c" />
                <add assembly="System.Web.Extensions, 
                    Version=1.0.61025.0, Culture=neutral, 
                    PublicKeyToken=31bf3856ad364e35"/>
                <add assembly="WssAjaxApplicationTest,
                    Version=1.0.0.0, Culture=neutral, 
                    PublicKeyToken=97d3f1fd9f5212b9"/>            
            </assemblies>
        </compilation>
    </system.web>
</configuration>

I've highlighted the key line (the line above it should have been merged into the file previously).  The bolded entry above is for the web application binary.

To test whether you've succeeded, you can simply point your browser to the URL: http://myserver/_layouts/mywebapp/default.aspx and you will have a fully AJAX enabled application using ASP.NET AJAX to connect to a .NET web service with prototype as a general purpose Javascript utility library (and you can even add scriptaculous on top of that for more awesome).

I've included a self extracting 7z file of the solution (see link below) if you'd like a quick start.  Note that the Microsoft SharePoint binaries are not included and you will have to add them back manually before the project will build.

Happy coding!

WssAjaxApplicationTest.exe (162.02 KB)
 Tuesday, August 14, 2007

Normalizing And Denormalizing SharePoint Field Names

8/14/2007 11:45:29 AM (Eastern Daylight Time, UTC-04:00)

Frequently, when working with Office, SharePoint, and SharePoint web services, it is necessary to convert between the "normalized" (hex escaped string) version of a field name.

To that end, I found a useful JavaScript tool for normalizing strings into SharePoint's "static name" format.

In .Net, we can simplify this using Regex and Uri.

    private static readonly Regex specialCharactersPattern
        = new Regex("[\\[*($%&)<>!?\\/\"{}\\s+-='@~`#\\\\:;^\\]]", 
            RegexOptions.Compiled);

    private static readonly Regex encodedCharactersPattern
        = new Regex("_x00(\\d{2})_", RegexOptions.Compiled);

    /// <summary>
    /// Normalizes the name of the SharePoint property name.
    /// </summary>
    /// <param name="key">The "human readable" key/property name.</param>
    /// <returns>
    /// The string with hex representation in place of special ASCII
    /// characters.
    /// </returns>
    private static string NormalizeSharePointPropertyName(string key) {
        return specialCharactersPattern.Replace(key, ReplaceSpecialCharacter);
    }

    /// <summary>
    /// Custom match evaluator to replace special characters within the input
    /// string.
    /// </summary>
    /// <param name="match">The pattern match.</param>
    /// <returns>The formatted version of the string.</returns>
    private static string ReplaceSpecialCharacter(Match match) {
        string replacement = string.Format("_x00{0}_",
            Uri.HexEscape(match.Value[0]).TrimStart('%'));

        return replacement;
    }

    /// <summary>
    /// Denormalizes the name of the SharePoint property.
    /// </summary>
    /// <param name="key">The normalized key/property name (static name).</param>
    /// <returns>
    /// The denormalized form of the input string ("human readable"
    /// with hex patterns replaced).
    /// </returns>
    private static string DenormalizeSharePointPropertyName(string key) {
        return encodedCharactersPattern.Replace(key, DecodeSpecialCharacter);
    }

    /// <summary>
    /// Custom match evaluator to replace the hex characters with special characters.
    /// </summary>
    /// <param name="match">The pattern match.</param>
    /// <returns>The ASCII format of the special character encoded in hex.</returns>
    private static string DecodeSpecialCharacter(Match match) {
        int start = 0;

        string replacement =
            Convert.ToString(
                Uri.HexUnescape(Convert.ToString(match.Value[0]), ref start)
            );

        return replacement;
    }

Download the sample console project to test it out.

SharePointNormalizationConsole.zip (4.35 KB)

 Sunday, June 17, 2007

Working With SharePoint Web Services

6/17/2007 7:03:15 PM (Eastern Daylight Time, UTC-04:00)

One of the most confounding things about working with the SharePoint web services is that the return values are all in XML strings (wrapped in an XmlNode).

To make working with the services even more puzzling, suppose you get a result like so:

<ContentType 
    ID="0x010100347433A509750F4D88880291599D314D04" 
    Name="My Content Type" 
    Group="My Custom Content Types" 
    Version="7" xmlns="http://schemas.microsoft.com/sharepoint/soap/">
    <Folder TargetName="_cts/My Content Type" />
    <Fields>
        <Field ... />
        <Field ... />
        <Field ... />
        <Field ... />
    </Fields>
    <XmlDocuments>
        <XmlDocument 
         NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
            <FormTemplates 
                xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
                <Display>DocumentLibraryForm</Display>
                <Edit>DocumentLibraryForm</Edit>
                <New>DocumentLibraryForm</New>
            </FormTemplates>
        </XmlDocument>
    </XmlDocuments>
</ContentType>

You would expect to be able to retrieve all of the <Field /> elements by executing the following code:

XmlNodeList nodes = xmlResponse.SelectNodes("//Field");

But it's not quite so straight forward.  You actually have to instantiate an XmlNamespaceManager with a bogus prefix:

NameTable table = new NameTable();
XmlNamespaceManager manager = new XmlNamespaceManager(table);
manager.AddNamespace("sp", "http://schemas.microsoft.com/sharepoint/soap/");

XmlNodeList nodes = xmlResponse.SelectNodes("//sp:Field", manager);

In this case, I used "sp" as my prefix. Notice that it's utilized in the XPath query as well. 

 Thursday, May 31, 2007

SharePoint SoapServerException When Using Lists Service

5/31/2007 4:19:43 PM (Eastern Daylight Time, UTC-04:00)

When using the lists service to query the "User Information List" (the SharePoint list where the users and groups is located), you may encounter the exception:

System.Web.Services.Protocols.SoapException:
    Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException'
    was thrown.
  at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(
      SoapClientMessage message,
      WebResponse response,
      Stream responseStream,
      Boolean asyncCall)
  at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(
      String methodName,
      Object[] parameters)
  at ListsDataServiceSample.SharePoint.Lists.Lists.GetList(String listName) in
      F:\Projects\Sandbox\SharePointWebServicesSample\ListsDataServiceSample\
          Web References\SharePoint.Lists\Reference.cs:line 213
  at ListsDataServiceSample.Program.Run() in
      F:\Projects\Sandbox\SharePointWebServicesSample\ListsDataServiceSample\
          Program.cs:line 28

This error will occur if you are not using the "Administrator" account, which of course, is not always ideal, especially if you are writing a client side app.

The solution to fix this is to grant the account permissions on the "User Information List":

And then give the user "Read" permissions on the list:

 Tuesday, March 20, 2007

Most Convoluted Licensing Model. Ever.

3/20/2007 8:33:57 PM (Eastern Daylight Time, UTC-04:00)

See if you can figure out how much your company's deployment of MOSS2007 will cost:

Mindblowingly convoluted.

 Saturday, January 13, 2007

Adding Users To A Document Workspace

1/13/2007 6:49:08 PM (Eastern Standard Time, UTC-05:00)

In WSS3, the process of adding users to a document workspace (or any sub-web) has changed from WSS2.  The following snippet will allow you to add a user (I've only tested with users mapped to domain accounts) to the workspace:

using(SPSite site = new SPSite("http://ashelia:2345")) {
    using(SPWeb workspace = site.OpenWeb()) {
        string resourceLogin = "ASHELIA\\cchen";

        // Ensure that the user exists and conveniently, get
        // an SPUser reference.
        SPUser user = workspace.EnsureUser(resourceLogin);

        // Create a new SPRoleAssignment for the user.
        SPRoleAssignment assignment =
            new SPRoleAssignment(
                user.LoginName, user.LoginName,
                user.Name, user.Notes
            );

        // Add the "Contribute" role definition to the role
        // assignment.
        assignment.RoleDefinitionBindings.Add(
            workspace.RoleDefinitions["Contribute"]
        );

        // Add the assignment to the web.
        workspace.RoleAssignments.Add(assignment);

        // Update the web.
        workspace.Update();
    }
}

Note that when you create a new sub-web, by default, there are 5 role definitions defined for you already.  These are:

  1. Full Control
  2. Design
  3. Contribute
  4. Read
  5. Limited Access
 Monday, January 08, 2007

ContentTypeIds In WSS3

1/8/2007 4:50:43 PM (Eastern Standard Time, UTC-05:00)

In WSS3, if you execute the following SQL:

    SELECT
        ContentTypeId
    FROM 
        ContentTypes

You will notice that the content types are represented in the output as hex.  If you take a look at the table definition, you'll see that the actual data type of the column is VARBINARY(512).

Doing a lookup like so:

    SELECT
        ContentTypeId
    FROM 
        ContentTypes
    WHERE 
        ContentTypeId = '0x101'

Will not work since you cannot perform a comparison between VARBINARY and a character data type directly.

Doing the following will also not work:

    SELECT
        ContentTypeId
    FROM 
        ContentTypes
    WHERE 
        CAST(ContentTypeId AS VARCHAR(512)) = '0x101'

This doesn't work because the underlying type of the binary data isn't character data.  It's integer data.  You can confirm this by running the following query:

    SELECT
        ContentTypeId,
        CAST(ContentTypeId AS VARCHAR(512))
    FROM 
        ContentTypes

You'll see that it's just a bunch of gibberish.  Try the same query with INT and you'll see that the data makes much more sense.  What you'll notice is that content types that inherit from a base content type will have numerical values that increment by 1.

This information is useful, but not nearly as useful as the data that you can glean from the hex string representation of the ContentTypeId.  You see, in the hex string representation, the base ID is a substring of the ID of any inheriting content type.  For example, if I have a content type which has a ID (as a hex string) of 0x0101345346345312234346, then any child content types will have 0x0101345346345312234346 as a substring (e.g. 0x010134534634531223434601, 0x010134534634531223434602).

So how do we get this data in SQL Server for comparison purposes?  We need to use an "undocumented" SQL function: fn_varbintohexstr().

This allows you to do nifty queries to find a given content type and all child content types (or any query where you have to retrieve information about a hierarchy of content types) like so:

    SELECT
        *
    FROM 
        ContentTypes
    WHERE 
        master.dbo.fn_varbintohexstr(ContentTypeId) LIKE 
            '0x0101345346345312234346%'

You can find out more information on this function here.

 Sunday, January 07, 2007

A Note On Copying Files In WSS3

1/7/2007 2:52:33 PM (Eastern Standard Time, UTC-05:00)

I dunno if this was supported in WSS2 or not, but in WSS3, when a file is copied to a new destination, a link is stored which indicates where the new document is copied from.

In the database, you can see this by running the query:

SELECT
    tp_dirname,
    tp_leafname,
    tp_copysource,
    tp_hascopydestinations,
    tp_guid,
    *
FROM ALLUSERDATA

The tp_CopySource column holds the URL of the source document from which the given file is copied from.  If you simply change the URL here, you can point it to any file you want.  If the file is a copy, then the following information bar will be displayed on top of the file properties in the properties page:

copy-indicator.jpg

However, it's not so obvious how to do this programmtically.  First, I tried using the CopyTo() method of SPFile.  Aside from not having the desired effect, this method does not seem to allow copying files across site boundaries (for example, from a root site to a document workspace -- for that, you have to use the Add() method on the Files property of the target SPWeb).

On my second attempt, I tried to set the "Copy Source" property of the file.

foreach (object key in file.Properties.Keys) {
    Console.Out.WriteLine("{0} : {1}", key, file.Properties[key]);
}

Iterating through the properties of an SPFile instance, I found that one of the properties, was "Copy Source" (internal name of "_CopySource") and in fact, held the URL of the source document.  I tried to set this value and update the file, but this was unsuccessful yet again.

On my third attempt, I came across the CopyTo() method on the SPListItem class and this did it for me :-) Conveniently, it also allows you to copy an item across site boundaries.

I felt so stupid afterwards because it should have been obvious that I had to use the CopyTo() method on the SPItem because the SPItem is also where the UnlinkFromCopySource() method is located.

RSS 2.0 Atom 1.0 CDF