james mckay dot net

Marco Arment (in a response to Jeff Atwood) came up with a list of five common complaints that are not valid reasons for hating a programming language:

• You’re unfamiliar with it.
• You don’t like the language’s vendors.
• Idiots often use it to write bad code.
• It doesn’t fully resemble your favorite language.
• You don’t like its syntax.

PHP’s not a perfect language, of course. Nothing is. But it’s by far the best language to use for nearly any web application, as long as you use an appropriate framework and good coding practices. Any language without either of those is bad.

I’d agree that PHP has its foibles, such as its lack of closures, its bloated global namespace and its ad-hoc, inconsistent approach to conventions. However, none of these are insurmountable, and in fact, once you get used to its foibles, working with PHP isn’t all that hard.

A few days ago I finished up on several days’ work on a PHP project and started on a SharePoint workflow. It’s an exercise that I highly recommend for anyone who is tempted to write an anti-PHP rant, because it will put everything in perspective, and give you a list of valid reasons for hating a programming language, platform or framework:

1. Vertical and infinite learning curve.
2. Unnecessary complexity.
3. Useless documentation.
4. Excessive pitfalls, gotchas and leaky abstractions.
5. Design that obstructs you from adopting best practices.
6. Meaningless, cryptic and uninformative error messages, buried in a massive log file deep in an obscure part of the bowels of your file system.
7. Painful debugging process.

Check this out: to debug a SharePoint workflow you can’t just hit run in Visual Studio. You have to attach the debugger to the w3wp.exe process, and even then it still won’t hit your breakpoints or break on exceptions. According to this blog post, you have to copy the .pdb file by hand into a part of the GAC’s directory structure that you can’t even access through Windows Explorer, so you have to do it via the command line. On top of that, the edit-compile-test loop is agonising — it can take two minutes to re-compile, deploy, and re-load your test site into your browser, after which you may well have to remove and restart the workflow.

Admittedly it’s not all bad. The vertical and infinite learning curve at least gives you some immense satisfaction when you finally “get it”. However, getting there feels at times like climbing the Inaccessible Pinnacle in rollerblades with your hands tied behind your back.

Comments (1) »

Posted at 15:58 in SharePoint

Please, Microsoft, make sure that when you put an article on your Knowledge Base, the solution or workaround you are proposing actually works.

Sharepoint websites insist on loading up an ActiveX control in a file called name.dll in Internet Explorer 7. This is a control that lets you see who in your organisation is logged on or something like that, and obviously it isn’t much use in a public facing web site. In fact it can be a bit of an annoyance to your end users as it pops up the information bar at the top completely unnecessarily.

It took a bit of Googling to find out where it was coming from, and that led me to this Knowledge Base article. The first two solutions, which involve asking your (probably technologically challenged) visitors to do things like putting GUIDs into the Windows registry, are about as helpful as cat poo, but the third — a server side solution — held out a bit of promise so I tried it.

Only to find that it didn’t work.

The offending file which is responsible for loading up name.dll is a Javascript file called init.js, located in

c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ 
    Templates\Layouts\1033

The Knowledge Base article tells you to make a copy of this file, edit out the line that loads in the dll, and change the reference in your master page to point to the new file. However, what it doesn’t tell you is that Sharepoint stubbornly adds a reference to init.js again seemingly from nowhere, thereby rendering this particular fix totally ineffective.

No, you’re going to have to edit init.js itself.

The problem here is that you want to minimise collateral damage. I haven’t a clue where in the bowels of Sharepoint administration they use this thing, or what the other crazy side effects of editing this file might be, and I don’t want to find out the hard way, so with no further ado, here is what I came up with.

The dll is loaded up by a function called EnsureIMNControl, which starts around line 1913. If you change the line in this function which says this:

if (browseris.ie5up && browseris.win32)

to say this:

if (browseris.ie5up && browseris.win32 && 
    (typeof(killNameControl) == 'undefined' || !killNameControl))

then add the following script block into the <head>section of your master page in which you want to kill off the prompt for name.dll:

<script type="text/javascript">    
  var killNameControl = true;  
</script>

it should stop it prompting your users to load name.dll on any pages that are using this particular master page, while leaving it up and running anywhere else that it may be necessary, and creating yet another bit of shrapnel that you have to deploy to all your servers in the farm.

Comment on this »

Posted at 15:11 in SharePoint

Sharepoint has two ways to transfer sites from one server to another: a web-based interface in Sharepoint Central Administration, or a command line tool called stsadm.exe. One of these methods is straightforward, reliable and simple; the other is a complete nightmare. Which do you think is the easier one?

“The web-based one!” I hear you all guess. “We don’t live in the dark ages any more! The days of typing obscure and arcane strings into a command prompt went out with the dinosaurs! Command prompts are for Linux hackers and Luddite nerds with too much time on their hands!”

Well, um, yes, that’s the theory. However, as with all things Sharepoint, it doesn’t work out that way in practice.

The web-based interface looks fairly straightforward at first. The backup option presents you with a long list of esoteric looking options on what you can back up and restore, but apart from that there’s not a lot to it, and within about ten minutes or so you have a directory on your server containing a stack of files that comprise ye backup.

So, you zip them up and deposit them on the new server and start up the restore wizard, and that’s where the fun begins. Chances are, straight away you’ll find it telling you that the backup doesn’t contain anything. It turns out that the backup directory contains a file called spbrtoc.xml which has buried in its innards the path to the subdirectory containing all the backup files. For some reason it is an absolute path, and in view of the fact that it is highly likely that this is different on the new server from what it was on the old one, you need to edit it. Go figure.

It doesn’t get any easier. Once you get it recognising that the folder you’re pointing it to does, in fact, contain a backup after all, it presents you with another bewildering array of options. You have to specify which URL to restore it to and umpteen IIS applications, application pools, databases, user names, passwords, and even where on the server to restore the databases to, and so on and so forth.

Once you’ve entered all the information into this great long convoluted form, you press OK and wait for the wizard to work its, erm, magic. The chances are that it’ll turn out to be a bit of a damp squib. Sharepoint needs write access to the backup directory to tweak the restore log files; if Sharepoint and your database are on different servers you need to be using a UNC path, otherwise one or the other of them won’t have access to the backup files in the same place; and there are a raft of other fiddly permissions issues that you need to sort out. So you correct them, and find that the next time you try it fails again because you hadn’t deleted the previous attempt from the list of tasks. Delete task, start over, make another mistake/discover another strange error, lather, rinse, repeat. On one occasion, we restored the content database and checked its contents in SQL Server Management Studio, only to find Sharepoint claiming adamantly that it didn’t contain any websites.

The fact is, there is so much scope to make a mistake here that it beggars belief, and if you’re not careful, you can spend literally days scratching your head over the event logs trying to figure out what on earth the problem could possibly be.

Now let’s look at the command line option, which you had probably written off in the first place thinking that command line options are for Linux hackers and Luddite nerds with too much time on their hands. It actually turns out to be deceptively simple. Once you’ve sorted out the small matter of finding stsadm.exe in the first place, and installed all the shrapnel that goes in strange places such as the GAC, obscure subdirectories of Program Files, web.config, and so on, you do

stsadm -o backup -url http://mysite/ -filename backup-filename.bak

on server A. This produces a single file containing your site and all the subsites, and you simply copy it over to and do

stsadm -o restore -url http://myothersite/ -filename backup-filename.bak

on server B.

Yes, that’s right, that’s it.

No XML files to edit. No permissions to set. No convoluted database options to put in. No failed previous attempts to delete from all over the place.

Just the backup filename and the URL, and you’re done.

The only thing I found was that for some reason I needed to create an empty web application and a site collection first, and restore on top of that using the -overwrite option of stsadm.exe, but apart from that, it worked perfectly. So perfectly, in fact, that we had to triple check that it hadn’t missed anything out or come up with some other strange gotchas.

Come on Microsoft, if you can make the command line option that straightforward, how come the web based version is such a minefield?!

[Update: It turns out that there is one particular permission issue that you need to watch out for. When you are restoring a backup onto an already existing site collection, you need to make sure that you are running stsadm.exe as a site collection administrator. Apart from that, it’s quite straightforward.]

Comments (4) »

Posted at 20:34 in SharePoint

For the past few weeks I’ve been pretty snowed under with some Sharepoint development work for a client. Since MOSS 2007 (Microsoft Office Sharepoint Services) is much more closely integrated into the whole Microsoft Office suite, you can’t afford to ignore it if you work in IT. Since Sharepoint development is a relatively new arena for me personally, I thought I’d post some of my initial perceptions of it.

Sharepoint development has a pretty steep learning curve. It’s a complex system with a lot of nooks and crannies to hide things in, and stacks of idiosyncrasies to get used to. Take managing the content and structure of your website, for example. You can do this through the web-based explorer (which you find on the main site administration menu under “Manage content and structure”), through another option on the same site menu entitled “View all site content” (which performs broadly the same function but with a totally different approach, even down to the context menus that pop up for each individual item), or through Sharepoint Designer. Like the web-based explorer, Sharepoint Designer gives you a view of your website in a hierarchical tree-like structure. However, the hierarchy is different. It took me ages to get used to the fact that one put the master page gallery directly under the site root as “Master Page Gallery” and the other called it “masterpage” and put it in a subdirectory entitled “_catalogs”.

Sharepoint Designer also seems to have something of a mind of its own when it comes to telling you what has been checked out and what hasn’t. There were several files in the site that it persistently and obstinately flagged as checked out even immediately after I had checked them in using Sharepoint Designer itself. This was a major irritation as it meant I had to go into the web-based interface to check them out again: being fully under the delusion that they were already checked out, Sharepoint Designer refused to give me that option on any of the menus. You can get round this by using the web-based explorer, but it’s rather annoying nonetheless. The Sharepoint expert who has been working with us on the project told me not to worry about this. “Sharepoint Designer is full of bugs,” he said. Very reassuring — not!

Then there’s the whole issue of accessibility, standards compliance and the horrendous markup that Sharepoint sees fit to churn out. Sharepoint has a very bad reputation for accessibility, and while MOSS 2007 has improved over Sharepoint 2003, it still has quite a way to go. WCAG “A” standard is probably within your grasp for a public facing website, but “AA” standard is considerably harder. Some of the markup that Sharepoint produces is seriously ugly. If you use Web Parts it insists on nesting them within tables within tables within tables — I found one place where the table nesting was no less than six levels deep, for instance. I came across an article the other day that tells you how to make your public facing Sharepoint website produce valid XHTML. It looks quite helpful, but I couldn’t resist the temptation to try running the article (which itself appears to be hosted on a Sharepoint installation) through the W3C’s validator service to see if it itself validated. It didn’t.

I’m pretty surprised that Microsoft hasn’t made it a priority to get products such as Sharepoint to produce valid XHTML 1.0 strict out of the box, with a totally clean separation between HTML markup, style sheets and Javascript. It’s likely to be a major stumbling block towards Sharepoint uptake, especially in the public sector. It’s all the more embarrassing when you consider how well some open source tools do in this respect. MediaWiki is one of the best examples I’ve come across to date, for instance. Although anyone can (and does) edit it, sometimes making it look pretty messy or even downright vandalised, it is always valid XHTML every single time. In fact, I defy anyone to find (or create) a page on Wikipedia that fails to validate.

What concerned me most, however, was the complexity of deploying your Sharepoint solution. It is unbelievably bitty. I’ve discovered the hard way that being able to perform deployments and upgrades in one or two easy steps is essential if you are to minimise the risk of making mistakes, and having clean, well-defined places to put things makes it much easier. However, Sharepoint takes a perverse delight in scattering the places that you have to put things to the four winds and complicating the process as much as it possibly can. You have to put compiled code into the Global Assembly Cache, some things into your web application’s virtual directory in IIS, and other things into a whole raft of subdirectories of:

c:\Program Files\Common Files\Microsoft Shared\web server extensions\12

You also have to make quite a bit of use of a command-line tool called stsadm.exe, which is in a subdirectory buried deep within the bowels of the above mouthful, and, guess what, the Sharepoint installation program doesn’t even think of adding it to your PATH environment variable, so you have to grub around with the search facility just to find it. Deploying your content itself involves restoring the content database from a backup, which may or may not work properly depending on a whole lot of parameters including the phase of the moon and what you had for breakfast, and if you make a mistake, the chances are pretty high that it will bluntly inform you, “Sorry, an unspecified error has occurred.” (Hint: set <customErrors mode="Off" /> in your web.config file to get any idea of what’s going on there.) And that’s before you get onto having to do an iisreset /noforce every time someone in Istanbul blows their nose.

Comments (2) »

Posted at 21:38 in SharePoint