https://www.thorprojects.com/wp-content/uploads/2015/07/MetalBox.jpg 200 200 Robert Bogue /wp-content/uploads/2015/07/Thor-Projects-Invert-Transparent-Logo.png Robert Bogue2005-11-08 21:03:002018-04-02 15:05:29CAML can take a long walk across the desert...
Back in March I attended a MS Book Publishers Summit in Redmond. I had the pleasure to sit down with Mike Fitzmaurice. What came out of his blog entry “CAML is Here to Stay“. I was the mysterious “guy” mentioned in the post.
Fitz’s post was reassuring – sort of . It told me that there would be some support for CAML and that there was hope for all of us struggling with the poor (ok, missing) documentation on CAML and how it works. I was encouraged because I knew how much of SharePoint requires CAML and how not knowing the rules for CAML hampers your ability to do anything in SharePoint – from queries to site definitions you’ll find so much CAML you’ll swear you’re in a desert. (Sorry, I had to get that one in.)
However, despite Fitz’s claims we still struggle to find good documentation on CAML. Every new bit of information on the topic seems to lead to more that remains undocumented.
The reason for this post is to make public one of the recent interactions that I had with the product support group – and the response I got. I think it illustrates the problems that I have with CAML – the challenges that I think all of us face.
I’ve got a set of utilities that allow you to migrate configuration data (web part placement, lists, etc.) from one site to another. (The utilities are not unlike the Echo utility from WinAppTechnology.) They rely upon the SharePoint object model to function because frankly they have to – not everything is exposed through the web services (Please make everything available via web services.) or the FrontPage RPCs (Please kill these off.) However, the problem with this is that it limits their ability to be used to a single configuration database. In other words, I can’t push configuration from development to staging. I’ve got a work around in creating a backup of a site in development, restoring it in staging, and using that as my template for changes.
This is difficult to do and requires manual intervention. The possibility for errors is fairly large. This approach doesn’t fly very well when you have a tightly controlled production environment – which most customers have. It ends up being a big issue.
So my current client and I found out that the template file (user site template – STP) is really a renamed cab file with a manifest.xml file in it. Manifest.Xml is CAML. So the thinking was that this would have what was necessary. To replicate the site. If the template can create a site surely it has all of the data about the site and should therefore be possible to use as a starting point to make updates.
Having this XML based serialization of the site means that we can pack up the file and use it as a template on another server. This means that we could have a very clean implementation for deploying from environment to environment. We started down the process of implementing this mechanism believing that we were well within guidelines. We weren’t touching the database – we were using a file that is in a supported format. Everything should be fine.
Well, that’s a good idea, but unfortunately, the word back from the development team is that they don’t want to support people using the manifest.xml file in an STP. At least they don’t want to support the areas of that file which are not documented CAML. They have a binary serialization of web parts in the file which they’re not planning on sharing the details to. The net effect is that it’s not possible to get web parts from an STP files Manifest.xml
That leaves me with very few options. Officially, I can’t use the data in a solution so I’d have to come up with my own mechanism for serializing this data – integrating that into the manifest.xml file and shipping that around. Of course, if I modify the schema to ship the web parts around I’m no longer moving CAML so there’s no telling if I’ll be able to use that data anyplace except in my application.
I’ve not yet figured out how to resolve the issue – however, I’m looking for input here. Am I the only one that thinks that if Microsoft says they’re going to support CAML that they should support it every time they write it out? Am I the only one who sees that this kind of “We’re supporting it” and then when we go to actually use it we get “That’s not supported” is making life really difficult?