WSS4: Is CAML really dead?

Gary Lapointe has just published some new information on WSS4 based on a few KB articles that Microsoft released just a few days ago. The KB articles relate to the upcoming SharePoint Service pack 2 and the upgrade checker.

It seems that the next version of SharePoint, also known as WSS4 or simply SharePoint vNext, will move away from CAML as a rendering language for list views and field types. Now, I do have a certain amount of knowledge pertaining to rendering of data using CAML, and if there is any truth to the rumors, all I can say is: Thank you, Microsoft. Thank you, thank you, thank you.

It seems that the ListViewWebPart from now on will rely on XSLT as the rendering language of choice. If you have never worked with custom SharePoint user interface development in views then you should really learn how, if only to realize how much better XSLT will be. CAML views are horrible, and many a fellow SharePoint developer is currently undergoing heavy psychiatric treatments from long-term exposure to CAML radiation.

The same seems to apply to custom field types. Custom field types in itself is a somewhat complex field, pun intended, and the rendering is more up to the developer than is the case for views. Still, any small advancement will make the SharePoint development experience better.

From the Microsoft KB article one can also read that something will happen to the custom Workflow actions architecture. These custom actions are used to add Workflow actions to tools such as SharePoint Designer 2007. The KB article only states that the file must be copied manually, although I do not see why this could not be done automatically unless there is more going on with the workflow infrastructure.

Of course, SharePoint 4 will likely use Windows Workflow Foundation 4 from the .net FX 4.0, so perhaps there are changes related to this.

All of this, by the way, is highly speculative. Don’t listen to rumors. I don’t know anything, but man do I hope for a change in CAML view design.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Debugging tips for SharePoint developers – Nasty Exception from HRESULT: 0x80040E2F

This really had me going for a while. I got this really weird problem the other night. I was setting up a metadata based document library with three SharePoint lookup lists. Basically there are three metadata columns that have lookup fields to other lists. The site owner needs to add new items on the metadata lists, so a Lookup column was the only sensible choice.

The three metadata lists, let’s call them A, B, and C, are initially only simple custom list like lists, so I decided to save some time and just create a simple ListTemplate and copy the schema to all the lists. Then I have a separate feature with ListInstances to create instances off these ListTemplates. Fairly simple, I do that all the time.

However, something really strange happened when I activated the list instance feature. The feature would throw an exception (Exception from HRESULT: 0x80040E2F) and remain deactivated, but the first list instance would be created. On the second attempt, the same thing would happen but the second list would be created. Feature still remaining deactivated. The third time everything was working and the third and final list would be created and the feature activated.

The ListInstance element was really simple:

Names and guid replaced with proper values, of course.

My good friend Sahil Malik pointed me in the direction of this article which explains the exact same symptoms and proposes that the problem is related to missing Id attributes in the ListInstance elements. However, adding Id attributes didn’t solve the problem, so I was back to square zero.

Long story short, the problem was that in copying the ListTemplate schema.xml files I also copied the Name attribute. Big mistake. Changing the Name attributes of the List element in the schema.xml file solved the whole problem. A day after I started… Dang.

Well, now I know. And so do you.


Pin It

Debugging tips for SharePoint developers – System.Runtime.InteropServices.COMException (0x80004005)

During an encounter with a custom list template I got stumped by the continuous appearance of a COMException conveniently just called 0x80004005. I hate those guys.

Now, I have done a few custom SharePoint ListTemplate deployments before, in fact I often write these more or less bottom up in a shorter amount of time than it takes to copy an existing list template and make it behave as I want. The problem today, however, is that I am a bit exhausted, and thus seems to overlook simple things. So, after spending an hour or so writing a fairly simple document library: Boom.

One thing is writing the damn thing while tired, a completely different matter is debugging SharePoint solutions or features while tired. Suddenly the list template that took an hour to make takes an hour to debug.

After reading the logfiles, and of course this was a project for a Norwegian customer, so Googling error messages

The culprit? Lack of BaseType. Yeah, I know. Adding BaseType="1" to the ListTemplate element resolved the whole thing. The devil is in the details. And I am a fool.

My advice: Keep your copy of the SDK documentation open. I know people say the documentation are bad, but if nothing else you can get some helpful hints when it comes to the required and optional attributes.


Pin It