Rory Primrose

Learn from my mistakes, you don't have time to make them yourself

View project on GitHub

Kicked it up a gear with ReadyBoost

A couple of years ago I bought a new Dell laptop. It was a middle range spec that I expected to throw more hardware at in the subsequent years. Sure enough, the hard drive became too small, too slow and the machine good certainly do with more than 2Gb RAM.

RAM was the primary concern. It was running out often enough that Vista was constantly going to virtual memory on a slow drive without much space to work with. I ran the analysis tool over at Crucial which to my complete surprise told me that the laptop only supports 2 RAM slots, each of which can only handle a capacity of 1Gb/stick. Surely this was not right. I searched the Dell site and found the specs for the hardware which told the same sad story. Dell in their wisdom sold a Vista laptop that was hardware limited to 2Gb RAM. So I’m not just surprised now, I’m utterly shocked.

Read More

Accessing performance counters on a remote machine

I just encountered a curly situation with performance counters. I have added performance counters to a WCF service which has been deployed out to a host platform. When I fire up perfmon.exe on my local machine, the counter category isn’t in the list of categories when I specify the remote machine.

All the research on the net seems to point towards a permissions problem. I am an administrator on the server however so this isn’t the problem. I can also see other performance categories and counters for that machine, but not the ones I have just installed.

The answer to this one is unexpected. A restart of the Remote Registry service on the server is required. It seems that the remote registry service uses some kind of internal cache of the registry. After restarting that service, the performance counters I’m after are now available to my local machine.

Read More

Getting Rhino mock to return a new mock type for the same interface

I am working with a bit of code (Manager) that involves caching values based on the type injected as a dependency (Resolver). The same Manager type can be used with different Resolvers and the keys used to store items in the Manager cache that are returned from the different Resolvers should be different.

To achieve this, I generate a cache key that identifies the manager (constant string), the assembly qualified name of the resolver and then the name of the item, TraceSource instances in this case. This means that two resolvers injected into two different managers that are asked to return a TraceSource instance of the same name, will be stored in the managers internal cache as two entries.

Read More

Setting registry permissions via WiX

I posted previously about creating EventLog sources without administrative rights. Part of this solution requires that account running the application has rights to create subkeys and write values to the EventLog in the registry. WiX is being used as the installation product so the answer is something like this for the registry key:

Read More

Class vs Struct

There is a lot of information around that discusses the differences between classes and structs. Unfortunately there isn’t a lot of information available about when to use one over the other.

MSDN has a good resource which provides guidance on how to choose between classes and structs. It starts by describing the differences between the two and then provides the following advice.

Consider defining a structure instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects. Do not define a structure unless the type has all of the following characteristics:

  • It logically represents a single value, similar to primitive types (integer, double, and so on).
  • It has an instance size smaller than 16 bytes.
  • It is immutable.
  • It will not have to be boxed frequently.

If one or more of these conditions are not met, create a reference type instead of a structure. Failure to adhere to this guideline can negatively impact performance.

Read More

Low impact WCF integration testing with SSL

I have been writing lots of tests for services and framework/toolkit type components over the last year. In both of these areas of development, I have written unit and integration tests that use WCF calls over SSL. Using SSL means that certificates are required. While an x509 certificate can be loaded from a file path, most implementations that use certificates rely on the certificate already being imported into a certificate store on the local machine. This means that the environment in which the tests are executed needs to be configured prior to running the tests.

This scenario limits flexibility for two reasons. Firstly, another developer can’t get the solution from source control and simply run the tests as they won’t have the required certificate installed. Secondly, a continuous build process will not be able to build the solution on a build machine that hasn’t already been configured.

Read More

Using StyleCop

SC is a great tool for keeping code style consistent. I don’t agree with all of the default rules though. Rules that you don’t want can be disabled using a Settings.StyleCop file. By default, each project will use its own settings file. Having to maintain a settings file for each project is very cumbersome. Thankfully, there is a better way.

The Source Analysis blog has a post about how settings are inherited from parent directories. This makes sharing settings between projects very easy. Here are some ideas for how to set this up and make the settings file easy to work with.

These instructions assume that all the projects in the solution are in child directories under the location that the solution file resides in.

Read More

Creating event log sources without administrative rights

I have been coming up against a scenario where I need to create new event log sources in an existing event log at runtime.

Using System.Diagnostics.EventLog

Administrative rights are required to create event log sources using the System.Diagnostics.EventLog class. Without administrative rights, CAS kicks in and a SecurityException is thrown.

System.Security.SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.

Attempting to create a new source or checking to see if the source already exists will enumerate all the event logs on the machine. This requires administrative rights because some event logs (such as the Security event log) are protected with specific security permissions. Without administrative rights, those event logs fail to be read.

Read More

Strict IErrorHandler usage

I previously posted about using IErrorHandler implementations for running error handling and exception shielding in WCF services. A few months after that post, Dave Jansen suggested that there are some risks in leaving it up to configuration to get the error handlers invoked.

The advantage of using configuration is that the behaviour of the service can be changed in a production environment without necessarily requiring the service itself to be recompiled. The disadvantage is that configuration could be either missing or incorrect.

Configuration is something that probably shouldn’t change independent of the dev/test/release cycle of a service, especially when it comes to error handling and exception shielding. This in itself means that minimal flexibility is lost if the error handler is compiled into the service rather than wired up through configuration.

Read More

The middle ground for code analysis custom dictionaries

I posted almost a year ago about using custom dictionaries for spell checking in code analysis. At the time, it seemed like a good idea to modify the custom dictionary in C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop so that any code on the machine will be evaluated against that dictionary. I’m now starting to swing away from this idea.

Having a custom dictionary in one spot on the machine is a good because any solution you use on that machine will adhere to that dictionary. The problem in a team environment is that the custom dictionary is not in source control. Any new dev machine will not have those changes and is likely to fail code analysis. Build servers will also suffer a maintenance nightmare with their custom dictionary as it will need to support all possible solutions being built, not just the ones on a particular dev machine.

If you swing to the other extreme, suppressing spelling failures in code is messy, but is in source control for other developers and build servers to benefit from.

Read More