Rory Primrose

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

View project on GitHub

Code coverage not available when debugging unit tests

Yep, this one bit me last week.

I had been writing some unit tests and debugging them. When the tests were finished, I kept wanting to look at the code coverage. All I would see was the message "Code coverage is not enabled for this test run". After trying lots of things and wasting 30 minutes, it turns out that code coverage is not available when debugging unit tests, even though code coverage is enabled through the testrunconfig file and that the build configuration is set Debug.

To avoid this mistake in the future, you can enable a warning message that specifically highlights the problem. Go to Tools, Options, expand the Test Tools node and select Default Dialog Box Action. There is an option called "When starting a remote test run or a run with code coverage under the debugger:". Set this value to "Always prompt". The next time that you run a unit test with the debugger attached, you will get a warning message saying "Debugging tests running on a remote computer or with code coverage enabled is not supported. The tests will run under the debugger locally and without code coverage enabled.".

No more confusion.

Read More

Using a Vista x64 network printer from Vista x86

I have installed Vista x64 on my server which has a USB printer attached to it. I have shared this printer so that other machines on the network can use it as a network printer. I found that I could see the printer from my Vista x86 laptop, but it just wouldn’t print.

The printer properties on the printer server have some advanced properties where you can specify x86 drivers for the printer for when clients add the network printer. The problem is that the printer drivers come with Vista natively. This means that the manufacturer (HP) doesn’t provide the drivers for it as a download. After some research, I found that there is a really easy way around this issue.

The rough steps are:

  1. Add a new printer to your x86 machine
  2. Select Local printer attached to this machine, uncheck automatic detection
  3. Select Create a new port and select Local Port
  4. Enter the address of the printer (\servername\printername)
  5. Select the printer make and model

Easy

Read More

Static Analysis Rules - Sooner rather than later

I posted the other day that I wanted to create some static analysis rules for Visual Studio. I have some great ideas for several rules that I want to write in order to do two things. Firstly, I want rules to pick up common mistakes made in coding. Secondly, the rules can be used to enforce coding standards via the Code Analysis TFS checkin policy.

To enforce coding standards, I have previously written xpath and regex TFS checkin policy implementations that work off a set of defined rules. I found that the xpath policy worked really well for files like csproj and sln files. The xml in these files is reasonably simple and the xpath queries are able to easily identify data that is missing or data that shouldn’t be included. I found it was a different story with the regex policy though. It became very difficult to be able to satisfy coding standards using regex on code files. It also only allowed for analysis of content within a single file, not what outside code calls into that file or other files that the code calls out to.

Enter the static analysis rules. It turned out that these are really easy to write. In about an hour, I have created four static analysis rules and tested them. The rules so far are:

Read More

WCF, SSL and localhost

We encountered an interesting issue at work over the last week. We are writing WCF services and implementing transport security to communicate with IIS. For local development, we had certificates created by a certificate server and configured onto the local IIS. As you would expect, the certificates used the machine name for the common name of the certificate. This is after all the standard procedure.

The problem encountered is that the web application project in Visual Studio stores the url of the project in the csproj file rather than the user settings file. This is the url of the application that Visual Studio will attach to in order to debug in IIS. The url has to be a reference to the local machine. As the project is under source control, the url stored as a project setting is now put onto the machines of other developers. So if I configure the project to point to my machine using https, check in the file and another developer gets it, then their version of the project now points to my machine rather than theirs. Bit of a problem.

There were two ideas that we quickly came up with:

Read More

Writing your own FxCop rules

Jason Kresowaty has posted an incredible amount of information about creating FxCop rules. I’ll get to these one day. One rule I want to write is a rule that checks for properties on a DataContract that are not assigned the DataMember attribute.

Read More

Scope Sneak

I came up with a new term today - scope sneak.

Sneak [sneek]: verb, sneaked or snuck, sneak·ing, noun

–verb (used without object)

  1. to go in a stealthy or furtive manner; slink; skulk.
  2. to act in a furtive or underhand way.
  3. British Informal. to tattle; inform.

Something happened at work today when a friend highlighted that some requirements had been snuck into a requirements document he was developing from. It occurred to me that this isn’t really scope creep (also seen here). Scope creep to me implies that everyone on the project knows that requirements are being added or changed (usually expanded). This situation was a bit more like requirements were added on the sly, hence scope sneak.

Read More

Incorrect code coverage references in testrunconfig

I have been having a problem with testrunconfig files recently.

Lets say I have developed a project with which I also have a unit test project in the solution. I have done this using the Debug build configuration. I set up the code coverage and everything is fine. I then make some changes to the code and also happen to change the build configuration. If I rerun the unit tests, Visual Studio starts freaking out.

When you select an assembly for code coverage, a relative path to that assembly is stored in the testrunconfig file. The issue is that the relative is specific to a build configuration. In this case, the testrunconfig points code coverage to the assemblies in bin\Debug rather than the path related to my current build configuration. But I have changed the code so that the assemblies in bin\Debug are out of date and don’t match the code being executed by the unit test under the current build configuration.

After talking to Microsoft about it, their workaround was to replace bin\Debug with the %OutDir% macro in the relative paths in the testrunconfig file. This macro gets evaluated and the correct build configuration path gets added into the path when the assembly path is resolved. This is not supported in the IDE so you will have to open the testrunconfig using the xml editor and modify the relative path by hand.

Read More

LogLevel NAnt Task

An ongoing issue that I am having with NAnt scripts is bloat in the log records being written to the screen and to disk. Tasks like xmlpeek and regex log messages that I am not interested in for the given logging threshold. It would be nice to not have these unwanted messages logged but for everything else to be logged as expected given the defined log threshold.

After doing some searching, I came across this post from Jay Flowers. Will Buttitta posted another version of the same idea in a comment against that post. Using tasks to change the logging threshold at runtime for a particular part of the script is a great idea. Unfortunately, I have found that neither of these implementations work.

After going through Reflector, I have found that classes that are derived from Task and call the Log method end up invoking Element.Log() which calls straight down to Project.Log(). The Project.Log method does not check the logging threshold before writing the log entry. What I haven’t been able to figure out is why Task.Log is not invoked. If it was, then I think the two solutions in Jay’s post would probably work as Task.Log() checks the current logging threshold before calling down to the base class.

Read More