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

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.

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.

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.

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.

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.

After implementing the double F1 solution a few moths ago, I now get continuously bitten by the change. I keep pressing F1 just once and then wait for help to come up only to remember that I need to hit F1 a second time. It probably doesn’t help that MSDN from Visual Studio takes a long time to come up the first time, but eventually I realise that I need to hit F1 a second time.

It’s a war between my automated single F1 press for help vs my misfiring over from the ESC key. I will keep the setting how it is though. Forgetting the second F1 press isn’t as bad as accidentally hitting F1 instead of ESC.

I have received an email report from TFS for a nightly team build that I have set up. The build ran the unit tests successfully, but failed on some of the load tests. The warning provided is Warning: only a part of test result was loaded because test type implementation is not available. If I try to open the test, I get a message box saying There are no Test Result Details available.

I had a conversation yesterday regarding WCF service contract design with my tech lead at work. Funnily enough, I then got a comment on an old post that afternoon from Ciaran O’Neill which is really about the same topic. I thought that I should write up my thoughts on the subject. See here for the article.

A good place to start looking at service contract design is the standards document published by iDesign (found here). This article contains some additional thoughts to add to these standards.

These ideas have come about because of a desire to achieve service designs that have minimum impact on configuration for both the client and the server. The intention is to design service contracts that will live happily with the default limits defined in WCF. The most common reasons for tweaking the WCF default configuration values are that services are returning data that is too large, or has too many objects in the graph for serialization.