• When I’m reading the file
• When I’m deserialising the xml

Obviously, I want to make sure that the file handle is released if the deserialisation fails. However, I can’t deal with that in a single try block, as if the exception is in the file IO, then the file handle won’t exist to close in a finally block! In other words, this won’t work:

try {
FileStream f = new FileStream(path, FileMode.Open, FileAccess.Read);
_fooList = (List<Foo>) fooSerializer.Deserialize(f);
} catch (Exception e) {
//handle File IO or Serialisation exception
} finally {
f.close(); // This line doesn’t work. Outside variable scope.
}

The problem is that if there is an IO exception, f won’t exist to close. Moving the definition of the FileStream to outside the try just causes a compilation error as the f.close() line may be using an uninitialized variable, so you have to check it first, like so:

FileStream f = null;
try {
f = new FileStream(path, FileMode.Open, FileAccess.Read);
_fooList = (List) fooSerializer.Deserialize(f);
} catch (Exception e2) {
//handle File IO exception or Serialisation exception.
} finally {
if (f != null) {
f.close();
}
}

That just seems, well, clunky. I’d prefer to have the variable scoped inside the try, as that’s where it is used, and the checking if f is null is just annoying. Initially, to solve this I came up with:

try {
FileStream f = new FileStream(path, FileMode.Open, FileAccess.Read);
try {
_fooList = (List<Foo>)fooSerializer.Deserialize(f);
} catch (Exception e1){
//handle Serialisation Exception
} finally {
f.close();
}
} catch (Exception e2) {
//handle File IO exception
}

Yuck! I don’t like that you have to handle exceptions in two places, and the complexity of two try..catch blocks, albeit that I liked having f scoped inside a try block. After some thinking, I found a better way:

try {
using (FileStream f = new FileStream(path, FileMode.Open, FileAccess.Read))
{
_fooList = (List<Foo>) fooSerializer.Deserialize(f);
}
}
catch (Exception ex)
{
//handle either File IO or Serialisation exception.
}

This works as the using{} block automatically calls dispose() on the object created in the top line of it (f in this case) when you leave the block, and dispose() and close() are synonymous on FileStreams.

Also, even if the using {} block doesn’t tidy up the FileStream when you leave because of an exception (and I’m pretty sure it does), you are now outside the variable scope of f, so the garbage collector will clear it up – which includes calling f’s finalizer (or destructor, for C++ bods) which in turn calls dispose() if required.

Thus, your file will not be stuck open.

Anyway, the short of it - the above pattern is a good way of opening a file and doing stuff with it, while handling errors in one catch block, and making sure that exceptions don’t leave the file locked open.

.NET has a thing called the common language runtime (CLR). (This is the .NET equivalent of the Java Runtime). Different versions are essentially different VMs, and can coexist. The CLR runs code that is an Intermediate Language (IL) (aka the Common Intermediate Language (CIL)). Whatever code you write in C# or VB.NET actually only gets partially compiled into IL code. It’s a lot like Java Bytecode.

The Base Classes are the library of DLLs for the framework (and are sometimes incorrectly referred to as the framework). Think of it as Win32 for .NET. These constitute the .NET API – and have different versions too. A different version of the base classes, though, does not mean a different CLR – for example, frameworks version 2, 3 and 3.5 all use the same CLR, but present a different external API and have different language features. Indeed, the base classes of framework version 3.5 are a superset of version 3, which are a superset of 2. This means framework 2 code will run on machines with the 3.5 installed.

The languages have different versions too, and this is where things start to get confusing. The different language versions have different compilers, which emit backward compatible IL. This is to be expected since there is no new version of the CLR. In plain terms this means that all the new language features can be used with older projects. E.g. C# 3.0 code can run on the .NET 2 Framework, provided you haven’t used any of the libraries that are part of a later framework. The C# 3.0 code will be partially compiled into the same version of IL code as your C# 2.0 code, so the only problems come if you are using libraries that aren’t part of that .NET Framework.

 (Note to self - must remember - C# version is independent of  Framework version)

So why would you want to use C# 3.0 over C# 2.0? Well, the language adds a number of new features too – such as automatic properties, relaxed delegates, object initialisers, type inference, anonymous types, extension methods, lambdas and partial methods.

Hopefully this chart might explain things a bit. I’m pretty sure it’s right, although I’m recreating it from memory and can’t entirely remember…

Similar chart here:

http://www.leonmeijer.nl/archive/2007/06/11/50.aspx

…though the Microsoft guy who presented to me didn’t say anything about a CLR 3.0. I suppose there may be one which is backwardly compatibile?

This control is a ‘Delegate control’ - that is, you can create features to override the currently used control. What my colleague wanted to do was not display the ‘Scope’ drop down list, the Advanced Search link, and to include prompt text (something like ‘Enter Search…’). A quick dig into the FEATURES folder in 12 Hive showed that the control had a number of properties.

(The features that this information applies to are the OSearchBasicFeature and OSearchEnhancedFeature. Both contain files called ‘SearchArea.xml’, and that contains the code below. I found the folders with this in:

%12 Hive%\Template\Features\OSearchBasicFeature

%12 Hive%\Template\Features\OSearchEnhancedFeature )

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Control
Id="SmallSearchInputBox"
Sequence="25"
ControlClass="Microsoft.SharePoint.Portal.WebControls.SearchBoxEx" ControlAssembly="Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
<Property Name="GoImageUrl">/_layouts/images/gosearch.gif</Property>
<Property Name="GoImageUrlRTL">/_layouts/images/goRTL.gif</Property>
<Property Name="GoImageActiveUrl">/_layouts/images/gosearch.gif</Property>
<Property Name="GoImageActiveUrlRTL">/_layouts/images/goRTL.gif</Property>
<Property Name="UseSiteDefaults">true</Property>
<Property Name="FrameType">None</Property>
<Property Name="ShowAdvancedSearch">true</Property>
</Control>
</Elements>

This shows a property ShowAdvancedSearch which sounded pretty promising for turning off the Advanced Search link. We decided to see what other properties were available, and found a good article by Clint Cherry about the SmallSearchInputBox control, and the MSDN docs. The Property tags in the XML for the delegate control set the properties of the web control class - e.g. GoImageUrl matches the GoImageUrl property on the class. Much to our pleasure, we found the QueryPromptString displays text in the search control which vanishes when it receives focus, and the DropDownMode property allows us to turn off the scope dropdown list. Hurrah!

For the values that you can set the drop down mode to, see the MSDN docs again

Hmm. Seems a bit brutal to me - I’d expected that the in progress workflows might be possible to continue, albeit that I wouldn’t expect to be able to start new processes. I suppose maybe it makes sense, ‘cos otherwise people would be able to still be using ‘in progress’ workflows for years afterwards, but it was a bit of a shock.

On the other hand, updating the licence wasn’t too hard - provided you can find the URL

A couple of my friends asked why I didn’t just use some albuming application, or something like Flickr, and tag the images. That way, I could browse by multiple criteria. And I’ve gotta say, it would be neat. However, I want to be able to look at these photos when I’m an old man. I mean, my grandfather was showing me pictures of when he was a kid - so that’s about 75 years ago. Does anyone consider 75 year survival times for digital media? Nope. But I suspect that file systems and JPEGs, even if they aren’t still in use, will be easier to migrate. Flickr? Well, obviously, no website has ‘Established 1932′ on it. I’m not sure I’d trust something like that to still be around. Other tagging and abluming products - again, I’m not convinced. I decided I’d stick with just folders.

This set me thinking about Record Management, and taxonomy vs tagging.

Tagging has a lot of benefits if you’re dealing with a lot of files. Essentially, you can have multiple views onto a pool of documents. That’s cool. And when we assign meta-data to a file (through use of Content Types), that’s sort of what we’re doing; enabling views onto a pool files. You can do that through either views on a list, or search, but the end result is pretty much the same.

Storing records by taxonomy alone has a number of issues - you have to be very organised, you have to make sure that people are saving to the correct location, multiple views onto the same files isn’t possible. But it has advantages too. It’s simple, and people can trust that the file is in a specific location, rather than something which may appear in a particular view.

And there’s the thing - simple, and trusted. And that’s what Records Managers like. They’re used to taxonomies of records; they call them File Plans. Heck, the practise of RM is usually doing in roughly the same way as filing cabinet, drawer, folder. The industry is used to its taxonomies, and used to things going in one location. Sure, just as tagging and taxonomy isn’t necessarily and ‘either/or’ proposition your RM system might be capturing metadata too - but for comfort and safety, Records Managers are always going to want a File Plan.

SharePoint’s record management doesn’t provide that. Sure, you can route content types to a particular library, and then place the files into automatically created folders, but that’s not really the same. And document libraries are awkward given the depth some File Plans go to. Given the idea that you’ll use search to find documents in your records repository, the position of the files in a hierarchy isn’t so important. And using search is, I think, a more realistic approach for a system with lots of records. But it means changing your approach to RM, it requires trust, and Records Managers are a naturally conservative bunch.

And that’s why I think although the technology is fine - fulfills the technical requirements and is probably more scalable - I don’t think it’ll catch on very easily. At least, not in UK Government. It’s a tough sell because it’s different, and isn’t as comfortable as simpler solutions.

Unfortunately, I then suffered a second problem - and error of ‘Value cannot be null’ when trying to deploy a workflow associated with a SharePoint Content Type. Sadly, all this was worked on last minute just before Christmas, so I’ve forgotten a lot of what I did to my machine. I met with some of the guys from K2 who were very helpful, and we did quite a lot. My memories are:

• Installed SP1 for [blackpearl]
• Installed Office 2007 (I was in a hurry and forgot, okay?)
• Stopped trying to associate the workflow with a content type and instead associated it with a specific list - which worked for the demo, but associating with the content type is a far, far cooler idea.
• Changed my form to allow “Cross-Domain Access for User Form Templates” and changed the data connection timeouts in SharePoint to be longer - as several of the guys in the thread noted, this does seem to be an issue with K2 workflows in VMs - but then my 2GB RAM machine was running a VM with MOSS, SQL2005, K2 and a DC, SMTP and POP services on it.
• Gave more rights to K2 to some of the users. I had to give the App pool more permissions than I had, in order to allow it to display worklists, which also makes sense.
• Sorted out a misconfiguration in IIS.

I’m sure I’ve missed other things, but it was so long ago now, I can’t quite remember. The only other thing I can remember doing was sitting around a lot waiting for everthing to work. The applications were quick enough when they’d been compiled, but that meant that the first time I hit some of the pages, well, there was a lot of waiting. And errors from timeouts. Particularly we had problems with contacting SQL Reporting Services from some of the K2 wizards, but found that if you waited a moment or two and then tried again then they were okay.