SP2007 Development

The circular logic of the WSS Lists Webservice GetListContentTypes call

Andy Burns, , , 6 Comments

So, I need to get a list of the content types applied to a library. The Lists webservice has a call for this:

<getlistcontenttypes xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<listname>string</listname>
<contenttypeid>string</contenttypeid>
</getlistcontenttypes>

So, I’m connected to a site, I supply a list name to identify the list… …but what do I give as a contentTypeId? I don’t have a f$%king clue – I was calling this function to try to find out what content types were valid!

Well, good news. It doesn’t seem to matter what you put in, you always get a list of all the content types on the list. I used the following code…

WS_Lists.Lists lsts = new WS_TestApp.WS_Lists.Lists();
lsts.Credentials = System.Net.CredentialCache.DefaultCredentials;
XmlNode node = lsts.GetListContentTypes(libraryName, contentTypeID);

I figured that maybe they wanted the base content type for what I wanted back, so I tried setting contentTypeID to documents (0x0101) and got back a list of all the content types. I then set contentTypeID to “fish”, and still got back a list of all the content types. As far as I can tell, the second parameter doesn’t do anything.

Side note: The first content type returned is your default content type.

Side note 2: There doesn’t seem to be an easy way of identifying non-visible content types…

The circular logic of the WSS Lists Webservice GetListContentTypes call

Are web services really that great?

Andy Burns, 1 Comment

So I’ve been working for the last few days using SharePoint’s web services extensively. They are pretty neat insofar as they offer a very public set of interfaces – the communication is pretty much human readable (for a given geekiness of human).

However, a couple of things have struck me. First was the bandwidth needed. Some of the calls I’m making were getting back 50k responses – and for a simple action in the app I’m working on, I could have to make lots of those just to display a form to a user. 1Mb downloads to show this form were likely – so this isn’t great. Presumably, enabling compression on the web server should reduce this considerably (looking at the XML in the file, it seems to have a high redundancy), but only at the cost of extra processing. Still, I can live with that.

The second, and in some ways more fundamental point, is that I find myself having to write wrappers for the various web services. I know, calling a web service in C# is dead easy, and that’s great, but the response -yuck! Everything seems to come back as lots of XML. And I do mean lots. I don’t actually want to deal with reams and reams of XML. Object oriented programming sort of implies that I should be trying to deal with objects. After all, that seems to be what much of ADO.NET is about – presenting data as objects.

So, for comparitively well known web services, can’t we have a pre-built wrapper so that I’m just dealing with objects? Both in and out. That way, well, if I want to talk to the web service via XML, directly, well, I can. If I’d sooner work with objects, then I could do that also. Just at the moment, there seems to be an asymmetry – I supply an function with parameters and it produces the request in XML. Then when I get the response, well, it’s just XML.

Hell, isn’t that what SOAP is all about? A common communication layer between remote objects?

In fact, thinking about it, some of the web service requests need XML put into them too – but that’s CAML, and another gripe entirely.

Are web services really that great?

Stupid bloody owssupp.dll

Andy Burns22 Comments

I am suffering a common problem still, despite uninstalling Project 2003 previously to try to fix a dll clash.

My system was working fine. I could open and edit documents from SharePoint just fine. Something broke it – and I believe (as in the article at the start) that that was Windows Update.

Now when I try and edit a document, I get the error

‘Edit Document’ requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.

Which is annoying, as I have this. I looked up the knowledgebase article, followed the instructions, and ended up trying to register/unregister the dll. Except that I can’t. When I try, and I get the error

The module “owssupp.dll” was loaded but the call to DllUnregisterServer failed with error code 0x80070716.

Apparently

This exit code means that “the resource name specified cannot be found in the image file”.

Ooookaaay. Risking my geek credentials, that is gibberish to me. Uninstalling and reinstalling SharePoint Support in the Office features did not fix the problem for me.I think I’m looking at a full Office reinstall. What a load…

Stupid bloody owssupp.dll

Error: The event receiver context for Workflow is invalid

Andy Burns, 1 Comment

This is an obscure error:

Error in commiting pending workflow batch items: System.InvalidOperationException: The event receiver context for Workflow is invalid.
at Microsoft.SharePoint.SPEventReceiverDefinition.ValidContext()
at Microsoft.SharePoint.SPEventReceiverDefinition.ValidReceiverFields()
at Microsoft.SharePoint.SPEventReceiverDefinition.

GetSqlCommandToAddEventReceivers(IList`1 erds)
at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.

CommitNewSubscriptions(Transaction txn, IList`1 erds)
at Microsoft.SharePoint.Workflow.SPPendingWorkBatch.

ProcessWorkItemBatch(Transaction transaction, Work method, IList`1 workItemBatch)
at Microsoft.SharePoint.Workflow.SPPendingWorkBatch.

Commit(Transaction transaction, ICollection items)

Let’s skip over wondering what an erd is (event receiver definition maybe?)- the solution to this is simple, but not obvious. Check you have created properties for TaskID, TaskProperties and Correlation Token. I found this solution at Robert Bogue’s blog. As a side note it is a REAL pain in the ass that setting up TaskIDs and TaskProperties is so manual – or at the very least that tasks with unassigned values for these do not appear with the red ‘warning’ exclamation mark in Visual Studio.

Error: The event receiver context for Workflow is invalid