Rory Primrose

I'm really looking forward to Code Camp this weekend (nerd camp my mother-in-law calls it). It should be a great weekend of sessions and networking. Hopefully I'll get to catch up with friends and meet some great new people.

See you there!

Tags:

I just saw the first episode in the latest season of the Gruen Transfer. The concept of the show is classic and the idea of “The pitch” is simply gold. Watching this episode reminded me of a pitch from last year about selling the idea of invading New Zealand. My favourite was the advert that lost the competition, but I just have to link to it for posterity.

Tags:

I’m heading off to the US and Canada for a holiday soon. I hope I can get some service like this.

Gold!

Tags:

As I was writing and using my custom GhostDoc rules (here and here), I was thinking that it would be nice if GhostDoc was able to clear the existing documentation and then apply the DocumentThis command. I emailed Roland Weigelt about the feature idea not realising there is a forum for feature requests. He quickly replied saying that the feature is already there albeit undocumented. This is exactly what I was after.

If you open up the keyboard bindings and do a search for GhostDoc, you will find a RebuildDocumentation command.

I have assigned the RebuildDocumentation to a Ctrl+Shift+D, Ctrl+Shift+R combination and changed DocumentThis to Ctrl+Shift+D, Ctrl+Shift+D combination. Roland said to make sure that the new keyboard binding is only used in Text Editor (as highlighted above).

Tags:

To follow up on my last post about documenting unit test methods with GhostDoc, a similar concept can be applied to documenting unit test classes.

Add a custom rule under the Classes section in the GhostDoc configuration dialog.

I have used the name "Matches unit test class" and identified type names that end with "Tests". I have entered the summary documentation with the following value:

The $(TypeName.ShortNameAsSee)
class is used to test the <see cref="$(TypeName.Words.Verbatim.ExceptLast)" /> class.$(End)

This produces much nicer documentation that the default documentation provided by Visual Studio.

Tags:

GhostDoc is one of the coolest tools around for Visual Studio. Sometimes it needs a little help though and unit test methods are a classic example. The format of my unit test method names usually identifies the method name, parameter list, parameter value conditions, expected outcome and end in "Test". The default rule that GhostDoc applies to this format is fairly ugly.

For example,

/// <summary>
/// Creates the returns cache store instance test.
/// </summary>
[TestMethod]
[Description("Black box tests")]
public void CreateReturnsCacheStoreInstanceTest()
{
    ICacheStore actual = CacheStoreFactory.Create();
 
    Assert.IsNotNull(actual, "Create failed to return an instance");
}

Creating a custom GhostDoc rule for unit test methods can assist in cleaning the documentation up a little.

First, open up the GhostDoc configuration.

Under methods, click Add.

Click Ok.

Enter the new rule name, identify that the method name must end in "Test" and fill out the summary using the value "Runs test for $(MethodName.Words.ExceptLast).".

Using this new rule, the example above now gets the following documentation generated.

/// <summary>
/// Runs test for create returns cache store instance.
/// </summary>
[TestMethod]
[Description("Black box tests")]
public void CreateReturnsCacheStoreInstanceTest()
{
    ICacheStore actual = CacheStoreFactory.Create();
 
    Assert.IsNotNull(actual, "Create failed to return an instance");
}

It's not perfect, but its a lot better.

Tags:

I've been on ADSL2+ for a few years now. Having a possible maximum speed of 24Gb is nice, but the actual floats between 5-7Gb being 3.5km from the exchange. That's not great, but is fast enough for general net usage. Tonight however, surfing the net has been slow. Really really slow. So slow in fact, that www.speedtest.net tells me this.

In the test before this one, the upload speed was actually a tad faster than the download speed. Did someone say broadband???

Yep, I'm glad that broadband in this country is so fast. My sarcasm drips all the way from this post to this article. Broadband in this country is a disgrace which is a real shame.

Update:

This morning is better :)

Tags:

I have written some custom SCOM management packs that read from a database and populate event collection data (see here and here for some examples from other people). My first management pack works without any problems. The second management pack (essentially a copy of the first) fails with an out of memory exception. The Operations Manager event log on the SCOM server contains an entry that starts with the following:

Converting data batch to XML failed with error "Not enough storage is available to complete this operation." (0x8007000E) in rule "[RuleName]"

This has been plaguing me for weeks but I now have an answer.

The definition of a collection event record includes a description field. The description field may be defined with a static value, a property bag (params) value or combination of both. The property bag value can be fully qualified (in the format of $Data/Property[@Name='<PropertyBagItemName>']$) or referenced by index. See here for more information.

My management pack originally contained the following:

<Description>%16</Description> 

In the case of my second management pack, the index is incorrect. There were field differences in the database output between the two management packs such that the param index was pointing to a different field from the database. I fixed this up so that it was pointing to a "Message" property bag value populated from the database.

<Description>$Data/Property[@Name='Message']$</Description> 

Now the management pack works. The difference between the two fields was that the original field (identified by index 16) had a null value whereas the "Message" field did have a value. My scripts deal with null values by ensuring they are always converted to empty strings using the following old VBA trick:

Call propertyBag.AddValue("Message", rs.Fields("Message").Value & "") 

After a bit of playing around, I found that there isn't a problem with the property bag containing empty values, but there does seem to be an issue with the event collection properties themselves having empty values when identified by index. If the fully qualified reference to the property bag item is used and it has an empty value, there is no problem.

Always make references using the fully qualified property bag reference in order to avoid this problem. This will also avoid problems should the structure of your property bag change.

Tags: scom