May 2007

29
May

How to stop your public facing Sharepoint site from loading name.dll

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
25
May

Cycle helmets versus style and comfort

I sometimes wonder why I bother wearing a cycle helmet when I take my bike in to work. As far as I’m aware they’re not a legal requirement here in the UK and personally I think that’s a Good Thing. I’ve been observing other cyclists when I go into work and back home again, and it seems that we helmet-wearers are definitely in the minority. They do make you feel safer, but I sometimes wonder if that feeling is more a palliative than anything else. They’re uncomfortable, they make your head sweat like crazy, they’re bulky and cumbersome, and they make you look a complete wuss. And if what Wikipedia says on the subject is to be believed, there is no conclusive evidence that they make the slightest bit of difference to safety in the first place.

Regardless of whether I wear a cycle helmet or not, one thing you’ll never see me wearing when I’m on my bike is lycra — that horrible figure hugging stuff that reveals the outlines of those parts of you which should really be treated with more modesty. It may be aerodynamic and all the rest of it, but personally I think it makes you look so awful that it’s embarrassing, even if you are fit and healthy. It screams that you’re one of those fitness freaks who view cycling as an end in itself rather than as a means to an end and don’t care if you end up looking a total prat in the process.

Comment on this »
Posted at 20:22 in Miscellany
23
May

Moving a Sharepoint site: there’s an easy way and a hard way

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
22
May

The functional beauty of JavaScript

I’m the kind of developer who tends to sit on the “coding” side rather than the “design” side of the fence. I’m at my happiest when I’m designing web services, database access and application architecture, and although I do enjoy the odd creative spurt with Photoshop and the like, I don’t find it as interesting as the former. Consequently, until a couple of years or so ago, I only gave JavaScript and client-side development the bare minimum of attention that I needed to do my job. What with all the lunatic inconsistencies that you needed to handle in order to cope with Netscape 4 and Internet Explorer 4, I always perceived it as a monstrosity that needed a lot of ugly hacks to get it to do anything more compelling than bring up a dialog box saying “Hello world”, and was content to merely download whatever scripts I could find off the Internet to make it do whatever I needed it to do.

These days, of course, the story is quite different: you have some nifty tools such as Firebug, and despite the myriad rendering bugs in Internet Explorer, standards such as CSS and XHTML make browsers are a lot more compatible with each other than they used to be, plus of course there is all the cool stuff that you can do with Ajax. All this makes learning JavaScript a much more attractive prospect, and not surprisingly I’ve had to do a lot more of it in the past couple of years than ever before.

It’s been a real eye-opener. Far from being the ugly, kludge-ridden monstrosity that I’d always thought of it as being, JavaScript is actually a beautiful, well designed language with some very nice constructs. I always thought of it as one of those linear, procedural languages much like VBScript or Fortran with some vaguely object-oriented bits and pieces thrown in as an afterthought like PHP 4, but in actual fact it has much more in common with functional languages such as Scheme, OCaml or Haskell. It has closures and first-class functions, for example, which means that you can express some things in very clever, succinct and beautiful ways.

One particular JavaScript framework that has gotten my attention in the past few months is jQuery, and it’s become my library of choice for DHTML and Ajax gee-whiz. It’s an increasingly popular and fully featured toolkit that enables you to do some pretty clever stuff with only a handful of lines of code. For a simple example of what you can do with it, here is a code snippet that will highlight rows in a table when you mouse over it:

var highlightColour = "#ffff00";
var normalColour = "#ffffff";

$(document).ready(function() {
  $("#my-table tr").hover(
    function() {
      $(this).css("background-color", highlightColour);
    },
    function() {
      $(this).css("background-color", normalColour);
    }
  );
});

I love the simplicity of this. As the WordPress guys say, code is poetry.

(Update: Jeff Attwood has an interesting take on the subject where he describes JavaScript as “the lingua franca of the web” with the likes of Flash and Silverlight as merely pretenders to the throne.)

Comment on this »
Posted at 23:43 in JavaScript
21
May

.NET by day, Rails by night

Here are a couple of interesting blogs for anyone who falls into the “.NET by day, Rails by night” category. Softies on Rails is a blog about Rails especially geared towards Microsoft coders by a couple of developers in Chicago, and A Fresh Cup is Mike Gunderloy’s new blog chronicling his reinvention of his career. (Gunderloy, for those of my readers who don’t keep up with who’s who in the world of software development, is a fairly well known author in the Microsoft world.) Back at the start of the year, he announced that he had had it with the Borg and was jumping ship. It looks like Rails is his framework of choice in Life After Microsoft.

Personally I’m not a great one for language wars. I tend to adopt a fairly pragmatic approach to the whole issue, which is why I do both .NET and PHP, as well as anything else that I am required to get my teeth into. Most of my development experience over the past six years has been in .NET, and I don’t see that changing too drastically in my day job, but I do think it’s a good idea to have some experience of other languages and platforms as well. A lot of developers only learn the bare minimum needed to do their jobs, and the result is often www.worsethanfailure.com.

Rails is a particularly good platform to learn as it teaches you all the latest best practices in web development: Model-View-Controllers, O/R mapping and the like, and important concepts such as “Once and only once” are drummed into you right from the word go. The Ruby language also contains a lot of advanced features such as closures and other functional paradigms, which can make for some pretty nice looking code. Plus, of course, there’s all the Ajax whizziness that can help you write really cool apps very easily.

Comment on this »
Posted at 12:45 in Rails
15
May

I am not as good at Trivial Pursuit as you think

I’ve been humbled. We played Trivial Pursuit at our church life group this evening. Guys versus gals. Everyone expected my team to win simply by virtue of the fact that I was on it, but unfortunately, we lost. :(

Contrary to popular belief, it turns out that I don’t know everything. Some people seem to think of me as a bit of a walking Wikipedia, and to be sure, maybe I have accumulated a bit too much useless information in my head from browsing said Wikipedia, but there is still a heck of a lot that I know absolutely nothing about. Such as celebrities, for instance.

The fact of the matter is that the latest version of Trivial Pursuit seems very celebrity oriented. I got the impression that the majority of the questions were about characters such as Britney Spears. Even some of the geeky questions were about Britney Spears. And I know nothing whatsoever about Britney Spears, other than that she’s a pop singer or something like that. I’ve never really followed the celebrity scene in any depth — I simply don’t tend to find it all that interesting.

I think this is probably why the ladies’ team won in the end though. Celebrities and the like tend to attract more interest from women. Cambridge psychologist Simon Baron-Cohen has published a book that goes into quite some detail about this kind of thing: he says that men’s brains are hard-wired for understanding and building systems, such as cars, computers and the offside rule in football, whereas women’s brains tend to focus more on empathising: subjects such as people, soap operas and Celebrity Big Brother. Make of that whatever you like (if you don’t like it, just put it down to the fact that he’s the cousin of the man behind Ali G and Borat) — I’m just making it my excuse for not sweeping the board with useless trivia about pop stars.

Comment on this »
Posted at 23:58 in Miscellany
14
May

Encounter at 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