The SharePoint client object model, chevy pickups and three important lessons.

If I could do it all over again I would take auto shop class in high school.  I didn’t know it at the time but I really enjoy automotive technology.  I have bought several text books used in automotive tech classes and read them cover to cover several times.  I have a small library of books on the repair and restoration of Chevy trucks and engines, and Chilton manuals for vehicles I'll never own.


The Chevy Advanced Design (’47-’54) trucks are my hands-down favorite (with the ’51 being my favorite of the mix) – but I’d “settle for” a Judge if the opportunity presented itself.


A few years ago I went and bought a 73 Chevy K10 pickup.  It was a good truck.  A manly truck.  A lime green truck.  I intended to get the vanity plate "SOYLENT" but the plate would have been worth more than the truck and nobody seemed to get the joke anyway.  I even finished a few projects on it (these should serve as evidence that I’m not a very good mechanic).  But when we moved from the Fargo area to North Carolina I sold the truck since moving it was not practical.


For a few years I had been reading all about how to repair a truck.  Before buying this truck I mentally rebuilt the Chevy 350 hundreds of times.  I had taken countless “end of chapter” tests on identifying and resolving automotive problems.  The only thing missing was the truck to prove how much I'd taught myself.


Got an electrical problem?  Well that’s simple … consult the wiring diagram to identify the relevant wires and fuses.  Check the fuses and connection ends, make sure you are getting power and have a good ground, and aren’t shorting out.  If all of that is good then start looking at the component that is not working (e.g. the wiper motor).


But the books never mentioned that the previous owner may have re-wired the system and not color coded the wires properly.  Or maybe the ground was cut when the previous owners kid tried to install a new stereo.  Or perhaps there is a build-up of rust that is preventing the body from grounding to the frame properly.  Or that 30 year old wires fall apart when you touch them.


It seemed so simple on paper.  It always does.


Migrating WSS content to TFS?  Piece of cake.  Just enumerate each WSS change and replay the action in TFS.  If you are doing an incremental migration then just enumerate those changes that have occurred since the last time you checked for changes.


So what is the method to enumerate all of the items in WSS?  Hmm … wait … how do I even talk to WSS?


And so begins my first rant on WSS.


The WSS converter has a few simple requirements:


1)      It will be able to run on a machine other than the TFS application or data tier and it will be able to run on a machine other than the WSS server (which is usually the TFS application tier).

2)      It will use the WSS provided APIs to interact with the document libraries.

3)      It will not access the WSS database directly.


Prior to this experience what I know about programming SharePoint could have been summed up in one word: “nothing”.  So I grabbed a book and hit MSDN.  I learned all about the SPWeb class and how to enumerate SPFile objects and man-oh-man life was good.  This was going to be easy. 


I setup a WSS server on my development box and started writing code.  The tests were working great.  I was just about to go grab my PM to show him a quick demo of my progress when I decided that it would be much cooler to demonstrate it by grabbing content from the production WSS site.  I updated the configuration to point to the remote machine and hit "F5"...


All of the sudden my code, my beautiful code, which had worked so well just moments earlier was dead in the water.  The WSS site couldn’t be found.  The document libraries didn’t exist.  The files were all missing.  How could this be?  I was pointing at the right machine.  The document library existed.  I had the proper access.  Why wouldn't this work?


I spent almost a full day debugging this before I found this web page on MSDN –  Please note these two really important phrases:


“You can use the Windows SharePoint Services object model in code running on the server to access and work with list or Web site data and templates, to customize Web Part views of list data, or to manage a top-level site or a subsite.”


“The Windows SharePoint Services Web Service provides interfaces for communicating with the server running Windows SharePoint Services from a remote computer to work with list and site data.”


Remember requirement #1?


I literally yelled.  In the event that children are present I won’t say what I yelled.  But I’ve heard that it is still hanging in space over Lake Michigan.


A week of learning and I was back to square one.


I took a walk (this was a twelve thousand step day), had a Diet Pepsi and start reading all about the SharePoint web services.


Three important lessons were reinforced from this experience.


Lesson #1:  If you need to support running on remote machines then do your testing on a remote machine from the beginning.


Lesson #2: Read the API overview pages on MSDN very carefully before investing time in reading the API.


Lesson #3: When in doubt, double-check that you have a good ground. 


Comments (5)

  1. SpoonsJTD says:

    I’ve never understood why effort wasn’t made to make the WSS OM remoteable. The web service API pales in comparison to the OM.

  2. Martin says:

    Looking forward to hearing your next rant when you get more in-depth with the WSS web services ;-).  If you want to have a chat sometime about the best alogorithm to use to take the flat tree of objects from the sharepoint services and turn them into a hierarchical object model I’d love to have a chat, it’s one of those things that you really don’t care about until you have to do.  I managed to get the problem down to a two-pass solution which I was proud of at the time but I’m convinced that there was a better way.

    Good luck,


  3. In my previous rant I made this statement (quoted out of context): Migrating WSS content to TFS? Piece

  4. Martin,

    I’d love to discuss your approach.  I start to discuss the enumeration of WSS items in today’s blog post but don’t really get into the nitty-gritty.


  5. Scott says:

    You should implement your own lightweight WS layer on top of the WSS object model.  Will give you much more flexibility than the WSS web service.


Skip to main content