The content types are deployed using a solution but that’s where the automation ends.  However, this is where Powershell steps up to the mark.  With Powershell we can quickly automate just about anything in SharePoint.

Here’s the script I can up with:

$web = Get-SPWeb http://www.example.com
$list = $web.Lists["TargetList"]
$list.ContentTypes | ForEach {
    $_.Name = $_.Parent.Name
    $_.Update()
}

To migrate the project I simply zipped the solution folder and copied it across to the destination machine, unzipped and opened in Visual Studio.

However, when I came to build the SharePoint solution file using the Tools -> WPSBuilder -> Build WSP, I got the following error in the output window:
“Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection”

When Googling the the error message the only result was on the WSP Builder CodePlex site and was about 64bit versions of the Cablib.dll assembly.  As neither of my machines is 64bit I figured this wasn’t the issue.

I’m not sure exactly what was causing the problem but this was the solution:

• Open the project folder in Explorer
  • Delete the bin folder
  • Delete the obj folder
  • Delete the wsp file in the project folder.
• Re-open the project in Visual Studio
  • Compile the project
  • Build the WSP (Tools -> WPSBuilder -> Build WSP)

After this everything was back to normal.

For work, I’m using a Windows 2008 Server virtual machine for doing all my SharePoint and .Net development on.  As it has got all of the cool stuff I’m working on, it is also the machine that I use to demo what I can do to clients.  Recently I’ve had a bit of a serge in the number of clients wanting to see Nintex Workflow 2007 (NFW2007) for SharePoint.

One of the cool features of NWF2007 is the whole Lazy Approval system, whereby users don’t have to go into SharePoint to approve to decline requests, they can just reply to the notification email with “approved”, “declined”, “ok”, “yes”, “no” or any other recognised word as the first line of the email.  In or to demonstrate this I need to setup and email system on my local machine.  The SMTP (sending) side of things is easy as it is built in to Windows 2008.  However, POP3 is a bit of a problem.  Previous version of IIS had a simple POP3 service but that has been dropped in IIS7.  The Microsoft way would be to install Exchange Server but that is a little too heavyweight for what I am trying to acheive.  Luckily a company called Visendo provides a free solution to plug the gap.  So now I can demo Nintex notification features.

Another feature I also wanted to demonstrate was setting up Active Directory accounts and then using those new accounts.  Nintex has got actions that allow you to interact with Active Directory but to then do anything usefull with the account required modifying xml config files and restarting the Visendo service.  But Nintex can call web services, so I’ve created a web service that has an AddAccount and DeleteAccount methods to update the Visendo configuration and restart the service.

Download:

I’ve made the source code for this web service freely available should anyone else want to have this sort of functionality: VisendoSMTPService.  The code is written against .Net 3.5 and is provided “as is” with no sort of warranty and is most definitely NOT recommended for live systems.  The code is released under a BSD License.

That in itself was nice and easy, it just required the use of a couple of UpdatePanel and UpdateProgress controls to be dropped on the page along with a ScriptManager control to handle the partial postback requests.

However, there were a couple of gotchas that I didn’t foresee.  Along with the partial updates, the client wanted the parts of the page to load the first time after the page had first loaded in the following order:

1. Load base page.
2. Start load of Application Status section.
3. Start load of Risk section.
4. Start load of Alerts section.

Unfortunately, the ScriptManager that comes with ASP.Net AJAX only handles one postback at a time.  Any subsequent postbacks take precedence over earlier request, which is fine if you only have one update panel on a page but this initially resulted in only the Alerts section being loaded – the other postbacks being canceled.

Luckily I found a very useful post on Amit’s Blog: Asp.Net Ajax UpdatePanel Simultaneous Update.  This post provides code that queues postback requests.  Ideally I would have liked to have the requests happening at the same time, but this is the next best thing.

The other problem that I found was that one of the sections on the page had previously been dynamically creating and reqistering script that got loaded and executed when the page loaded using:

Page.ClientScript.RegisterClientScriptBlock(this.GetType(),
    "ShowNavBarItem", script.ToString());

Unfortunately that doesn’t work with the AJAX ScriptManager.  Instead I had to change the code to use the ScriptManager to load and execute the code using the following:

ScriptManager.RegisterClientScriptBlock(updatePanelApplications,
    typeof(UpdatePanel), "showNavBarItems", script.ToString(), true);

This means that each time the section is updated I can re-generate the script and it will be executed again.

With this AJAX loading and some enhancements to the SQL code, users now get a much fasted load and response time for the page as the no longer have to wait for the whole page to be rendered before seeing information appearing on the page.

Recently, however, I have been involved in developing a customised search solution using Microsoft Office SharePoint Server (MOSS) to allow a client to search client and non-client related documentation within their organisation.   What I rapidly discovered is that enterprise search is not a plug-and-play affair.  A lot of thought needs to go into the meta data that is used to define the taxonomy of the data (in this documents) and also how users are going to interact with search and how to make sure they get the information they need.

I have also recently been on a training course at FAST Search,which was acquired by Microsoft in April 2008.  The course was both an introduction to the structure of FAST ESP and also an in-depth look into customising the internal, both feeding content into the indexing engine of FAST ESP and building a rich user experience for getting content from the FATS ESP search engine.

The two activities have really awaken me to how powerfull enterprise search can be in empowering users to find information which previously they either may not have know how to access or, more likely, simply hadn’t known existed.  Whilst I was learning about FAST Search, it was generally anticipated that it would be included with the next generation of MOSS.  Today that was confirmed at FASTForward ’09 when Microsoft announced its roadmap for enterprise search which has two initial streams, firstly FAST Search for Internet Business which is mainly aimed at internet retail businesses – like you’d use to find products on Amazon.  The second, and more interesting for me, stream is FAST Search for SharePoint, which will integrate FAST Search more closely with SharePoint and would be used for the type of internal information discovery that I have been working on recently.

Mark Harrisson also noted on his blog that Microsoft is going to be offering ESP for SharePoint immediately which is

a special offering that allows customers to purchase high-end search capabilities today, with a defined licensing path to FAST Search for SharePoint when it becomes available.

I haven’t been able to find out more information about ESP for SharePoint, but it certainly looks like it could be an interesting product to get hold of.  I the mean time I’m keen to continue working with MOSS Enterprise Search and have just the right project lined up to flex my new found love of search on.

try {
    //many lines of code
catch (Exception ex) {
    throw new Exception("Something went wrong dude!");
}

This is probably the single most un-helpful piece of code a developer can write.  All you are doing is making you life and future developers lives harder when it comes to debugging.  The whole point of the try…catch block is for times when you know an exception may happen and it allows you to gracefully handle it without the whole system crashing to the ground.

So lets have a closer look at what’s wrong with this code:

Too many lines wrapped

You wrap code in a try…catch block the idea is to only wrap the code that is likely to throw an exception.  Whilst it isn’t impossible, it does make identifying the offending line of code harder to find.  This may sound like a trivial reason to complain but when you have to deal with this day after day it does get a little tedious.

Indiscriminate exception handling

By catching exceptions of type Exception you’re really saying to developers that come after you “I don’t care enough about this code to know what exceptions might happen.â€?  In many instances different exception types can be handled in different ways.  I’m betting that the default response of most developers that catch Exception will be to throw a cryptic message at the user and drop out of whatever the method was – probably without clean up resources either.

It is possible to have multiple catch blocks that catch different exception types if you think that there are multiple types of exceptions that might be thrown:

try {
    File.WriteAllText"(@"c:\test.txt", "Hello world!");
}
catch (FileNotFoundException ex) {
    // do something
}
catch (SecurityException ex) {
    // do something else
}

This means that you can handle different exceptions in different ways.  Also, any type of Exception that you don’t handle gets passed up the call stack.

The exception isn’t handled

In this particular instance the exception isn’t handled, so why on earth put the try…catch block there in the first place?!  If all you’re going to do is throw a new exception or re-throw the old exception without doing anything you’re better off leaving out the try…catch block.  It just adds overhead to instances when it runs through without exception.

Original exception is masked

Again, in this example a new exception is thrown.  If you must do this then at least include the original exception as the inner exception (the exception that cause the new exception to be thrown).  The Exception class even has a constructor to help with this:

public Exception( string message, Exception inner )

Alternatively, you can throw the original exception.

New exception is generalised

By throwing the base Exception class you are forcing developers that use your code to have to catch exceptions of type Exception – see above for why this can be bad.  If you can’t find a built-in exception class to use, and there are many, create your own.  Visual Studio 2008 has a code snippet for creating an exception class, all you have to do is fill-in the blanks.

In an ideal world…

… I’d like .Net to have a similar method to java of having to specify (use attributes) what exceptions a method throws or catches.  This allows you to easily find out what exceptions may originate in a method your code calls, and let other developers know what exceptions your code doesn’t handle.  It also allows for pretty good compile time exception checking.  It means extra code has to be written but I think it results in better code.

I personally prefer desktop GUI applications and so, based on code by Liron, I’ve created my own desktop Event Receiver Manager.  It allows you to select site & list, browse for an assembly so it can give you the full assembly name and a list of classes inside, and a list of receivers you can attach to.

The current version only allows adding new event receivers.  Before adding a new receiver it will check to make sure the same receiver doesn’t already exist.

Future plans for it include listing existing receivers to allow users to delete them but as I don’t need to do that myself yet I haven’t implemented it.

Download a copy of EventReceiverManager.

I have made both the source code and pre-compiled binary available for download under a BSD license (share, remix, no endorsement).  It is written in C# and requires the .Net 2.0 framework, if you want to compile the source you will probably require MS Visual Studio (Express should be ok), although it may work with SharpDevelop or Mono.

It is a console application (sorry, no pretty GUI this time) that reads the contents of input.txt (in the same directory as the app), it then counts the occurrences of each character and outputs the results to the console. Simple!

If you make any improvements to the code please leave a comment and/or email the changes to me: gringod [at] gmail [dot] com.

Recently I’ve had reason to take an code library written in C++ and port it to C#.  Whilst I dabbled in C++ on a compilers course at university, I hated it then and I still hate it now.  I personally think it’s an abomination and should be consigned to the great garbage collector in the sky.   Whilst I can just about read the C++ syntax there is a lot that I don’t understand about it.

The library I was porting had semi reasonable documentation outlining what classes exist and their methods and a brief description of the overall usage.  This gave me a good starting point, however the documentation didn’t include example usages and expected results, for this I was forced to delve into the code.

One development paradigm I have been interested in but have been unable to find a decent project to test it on is Test-Driven-Development and this seemed like the perfect project to try it on.  So I set to work on the first iteration getting the test set up.   Without knowing exactly what results I should be expecting I was finding it hard going, so once again I dived back into the old code.

Thankfully, the developers of the C++ library had create a fairly comprehensive set of unit tests and with my limited C++ knowledge and a text editor with RegEx Find & Replace I was quickly able to convert their unit tests into NUnit based unit tests.

For example, what started out life as:

 1: void test_row_multiply_change(void)

 2: {

 3:  row r;

 4:  RINGING_TEST( ( r *= change( 6, "X" ) ) == "214365" );

 5:  RINGING_TEST( ( r *= change( 6, "1" ) ) == "241635" );

 6:  RINGING_TEST( ( r *= change( 8, "X" ) ) == "42615387" );

 7:  RINGING_TEST( ( r *= change( 5, "3" ) ) == "24651387" );

 8:  

 9:  RINGING_TEST( row( "214365" ) * change( 7, "5" ) == row( "1234675" ) );

 10: }

Quickly became:

 1: [Test]

 2: public void TestMultiplicationByChange()

 3: {

 4:  Row r = new Row();

 5:  Assert.AreEqual((Row)"214365", r *= new Change(6, "X") );

 6:  Assert.AreEqual((Row)"241635", r *= new Change(6, "1"));

 7:  Assert.AreEqual((Row)"42615387", r *= new Change(8, "X" ));

 8:  Assert.AreEqual((Row)"24651387", r *= new Change(5, "3"));

 9:  

 10:  Assert.AreEqual((Row)"1234675", new Row("214365") * new Change(7, "5"));

 11: }

Now, with a full set of unit tests at my disposal I was quickly able to bash away at the library and very quickly got working code without the need to trawl through ghastly C++ code.

Hooray for Test-Driven-Development and three cheers for Test-Driven-Porting.

ps. The library I’m porting is an open source library for Bell Ringing – yes I know I’m a geek but anyone that has followed everything else in this post must also be a geek .  Once I’m finished I will be releasing my code under an open source license as well, I just need to pick the right one.

pps. I may have exaggerated my hate of C++ a little.  I believe all languages have their place, even the esoteric languages like LOLCode.

With the release of the .Net platform,  Microsoft gave developers that need to handle file system operations a wonderful, but underused, utility class: System.IO.Path.  One of the methods on this class is Combine().  It take two arguments: path1 (string) and path2 (string), and intelligently combines them.

That’s it!  No more messing around with string concatenation or endless if statements or figuring out if it should be a forward or backslash… just Path.Combine().