The circular logic of the WSS Lists Webservice GetListContentTypes call

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?

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

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

Installing WSS Search – Account names must be of the format [DomainUser]

Just [user] doesn’t cut it!

I was installing a MOSS system yesterday, and starting the WSS search service was causing me problems. I kept getting errors of the form

SearchServiceInstance.Provision (server ‘VM-AWB-MOSS01’) failed. Setting back to previous status ‘Disabled’.

Well, a google trawl turned up a fairly obvious solution – which just didn’t occur to me. Make sure the account name includes the domain!

Thanks Bergen!

Installing WSS Search – Account names must be of the format [DomainUser]

Don't put your Record Center in a Collaboration Site Collection

Don’t be lazy like me. I put my Records Center in a collaboration site collection, ‘cos I was lazy and didn’t want to set up navigation links, etc., between site collections.

Unfortunately, I found that when I then tried to submit documents to the records center, I kept getting the error “Records Center Records Center is not properly configured for this request” (Note: my records center is called Records Center).

“Weird”, I thought. The URL to the web service used for submitting files was correct. The records center itself seemed to work correctly. SharePoint Logs and Windows Event logs showed the same error about not being properly configured, but that was all. I couldn’t see anything wrong with it.

So in the end I got hacked off, and just recreated my records center in its own site collection (as you’d problably want it, to be honest). And Bingo! It worked!

So kids, Don’t be lazy – put your Record Center in its own site collection.

Comments from my old blog:

Yup, I’ve found other people have had the same issue – and have done the same thing – use a separate site collection.

By Andy at 16:47:42 Tuesday 13th November 2007

Don't put your Record Center in a Collaboration Site Collection

If search isn't indexing your SharePoint sites, try fully qualifying your domain name.

I don’t know why this wasn’t working, but search on my SharePoint VM wasn’t indexing the collaboration portal that was our top level site collection – indeed, it wasn’t even crawling it. So I changed the start path to the fully qualified path (e.g. http://vm-moss07/ to http://vm-moss07.dev.deltascheme.com/), and now at least a few pages were crawled – those being, unfortunately, the pages that redirected to the ‘not fully qualified’ path. So I put both into the content source – and it crawled the whole site collection correctly.

I’m really not sure why, to be honest. I haven’t checked the alternative access mappings, but I don’t see why the search didn’t work without the fully qualified server name. The crawling of the My Sites and Central Admin site collections worked fine without being fully qualified.

I’m sure it’s something simple – any guesses anyone?

If search isn't indexing your SharePoint sites, try fully qualifying your domain name.

The lunacy of the SharePoint DatePicker control

More branding – I’d rebranded the SharePoint calendar. It looks nice, and not ‘SharePoint Blue’. “Great”, I thought, “I give that a quick check and move on to the next task”. So I gave it a check – and found that while the DatePicker that appears in the left navigation of the page was fine, the DatePicker control which appears for Date & Time fields had not picked up the styles I’d defined.

Arse. Mine was supposed to be red, not blue. So I began to wonder where this control was actually coming from. It wasn’t coming from my page – viewing the source, it wasn’t there, and if it had been I’d’ve expected it to be styled.

I didn’t think it was dynamically produced by JavaScript – I was sure there was an .aspx file behind it. I had a nasty feeling, so I went and checked the _layouts directory, but didn’t see anything that looked related to DatePickers.

Next up I tried the IIS logs – and found it. I was right – the DatePicker was being generated by iframe.aspx – and it was in the _layouts directory. (This makes me wonder – is this the only place where an iframe is used in SharePoint? Would something like datepicker.aspx or even datepickeriframe.aspx not have been a more obvious name?)

Anyway, so it’s in the _layout directory. It’s trivial to change it so that it also uses my stylesheet – but that will change it farm-wide, or configuration changes. I guess I’ll be looking at kb-944105 how to customize application pages in the layouts folder in wss 3 and moss 2007.

Edit: Michelle has an excellent suggestion, and she’s blogged about it here. It’s still a hack, really, but there are worse ones!

The lunacy of the SharePoint DatePicker control

Hover Styles in OOB SharePoint

Okay, this is going to sound really pedantic, but this is really annoying me. In default SharePoint there are a number of buttons. These buttons have text on them. When you roll you mouse over the button, the background and text changes colour. However, as the text does not have the same area as the whole button, the regions in which the hover occurs are different. For example, see the image below…

So, as you can see, the button turns oranges, and then the link turns black.

Now, this isn’t a problem in the default styles – the change from blue to black is very small. But you can’t guarantee that this is the case for rebranded sites – and of course, in mine it was a big difference.

And the crazy thing is, well, the button area’s style is being changed by JavaScript – that’s what makes it turn orange. So you can just use that style change to change the colour of the link text. Why define an hover pseudoclass for it?

Anyway, that’s what I did while tidying up my design.

Hover Styles in OOB SharePoint

The stupidity of Search boxes when branding SharePoint

Okay, so I just made an interesting discovery. In the master pages on SharePoint there is a content placeholder called PlaceHolderTitleBreadcrumb. A slightly odd name – I’m not sure it should have ‘title’ in it, as that seems to make assumptions about how you’re going to use it – but in fairness, it is a placeholder for breadcrumbs. Great!

Except if you go the search page. Then, the search box is shown in the breadcrumb placeholder. WTF! Who the hell designed that? I mean, what idiot decided to put a large control, with LOTS of padding (discussed wonderfully by Heather Solomon).

Speaking of padding – that padding is hard coded into the control. It is fucking CSS, but they put it into the control. Nobody would ever want to get rid of that 50px padding above this control, right? Nobody would have designed space for the nice little breadcrumbs only to be caught out when the stonking search control sticks it’s flabby ass there, right?

Wrong. I’ve been caught, and I’m not the only one. As Tom says, the solution isn’t complicated – but I shouldn’t have to solve it. He’s right when he discusses the ‘contract’ of the master page. This design bug is just wrong.

And I don’t believe that I should have to write my own delegate controls all the time ‘cos someone was too lazy to write theirs in a generic way. I mean, this is supposed to be the office platform. Don’t hardcode styles into your delegate controls, don’t assume your control will be in a table row, and, in fact, could we stop using tables so we might make an accessible system? It’s kind of important in many countries…

The stupidity of Search boxes when branding SharePoint