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.

Ever wondered what the correct format of a GUID value is? Ever needed a RegEx to validate a GUID as a string value? Check out Nicholas Allen’s latest post for a good hint.

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.

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.

I have found that several of my VS2008 solutions are not able to calculate code metrics for a couple of their projects. The error message returned is:

An error occurred while calculating code metrics for target file ‘<File path>’ in project <ProjectA>. The following error was encountered while reading module ‘<ProjectB>’: Could not resolve type reference: [mscorlib].

After consulting David Kean and Todd King at Microsoft (FxCop team), they have found the issue. Todd’s response was:

It looks like we have a bug in metrics where if one of your project’s reference assemblies uses an attribute that lives in an assembly that is not one of your project’s other reference assemblies metrics will fail because when it goes to try to populate all the attributes on your reference assemblies because it won’t be able to find the type information for that attribute. We are tracking this bug and should have it fixed in SP1. For now the workaround is to add a few extra references to some of your projects.

I found this issue when developing WCF services. The problem scenario was because of WCF attributes in a service contract assembly being referenced by a service host where the service host didn’t reference System.ServiceModel. The service host compiles, but failed to have code metrics calculated for it. A simplified repro example is ProjectA references ProjectB which references AssemblyC. ProjectA fails to calculate code metrics because it doesn’t reference AssemblyC.

There is a second bug here as well. The error message points to mscorlib as the type reference that couldn’t be resolved. This is not correct and is misleading.

Todd has said that this bug will be fixed in SP1. Until then, the workaround is to look at the references in ProjectB that are not in ProjectA. Gradually add the missing references until code metrics can be calculated.

Here is my scenario:

I have a static method which checks some static generic dictionaries to determine whether keys exist. If keys don’t exist, they will get added along with a value.

Rough "metrics" will be:

• the static method will get called a lot
• items will rarely get added to the dictionary
• items are never removed from the dictionary
• the dictionary will only contain a few items
• as many times as the method is called, the dictionary will be referenced using the ContainsKey property (and the indexer property where ContainsKey == true)

In order to ensure thread safety of adding a new item to the dictionary, a lock is required. Two options I see are as follows:

I have started using the very nice automatic properties in VS2008. As I was using these, I was thinking about how they work when you define the property as read-only or write-only. Without a backing field, you wouldn’t be able to read from or write to the backing field, rendering the property useless.

I coded an automatic property in this way and didn’t get any error indication from the IDE, but I didn’t actually compile it. I have since run some code analysis that suggests that my collection properties should be readonly. As these properties are automatic properties, I then removed the setter and compiled.

Boom! Now there is a compiler error CS0840 that includes the message "Automatically implemented properties must define both get and set accessors". It is unfortunate that this wasn’t indicated with those helpful squiggly red lines in the code editor, but not a major problem.

I posted previously about using the InternalsVisibleTo attribute for unit testing and how I had come across David Kean’s very helpful PublicKey application. I have been using this application for the last month or so and it has been great, until yesterday.

I changed the snk file used by my solution. This caused an interesting Catch-22 situation. AssemblyA couldn’t compile because it had an InternalsVisibleTo attribute pointing to AssemblyATest, which now has the wrong PublicKey value. AssemblyATest couldn’t compile because it directly references AssemblyA in order to run the tests.

Unfortunately, David’s PublicKey application works from binaries alone. Because I can’t compile the assemblies, I can’t regenerate the InternalsVisibleTo attribute with the correct PublicKey value.

This is an interesting one. I have a solution for a WCF service that contains the business and data access layers. When I run code metrics for the solution, two of the projects fail. One is the IIS service host project, and the other one is the business layer implementation project.

Both projects fail because they can’t read another module. The modules that they can’t read are direct project reference. The reason provided is:

Could not resolve type reference: [mscorlib]

There is no information about this on the net that I can find. Is anyone else finding this problem?

VS2008 Code Analysis has new features that provide spell checking. This is really great, but sometime you need to provide some additional information as to what valid words are. This is normally due to the spell checker not knowing your company name and product names. Quite understandable and thankfully it is configurable.

If you look at the help for the Identifiers should be spelled correctly rule, it refers to a custom dictionary. Unfortunately, the help documentation is quite unhelpful where it indicates where the CustomDictionary.xml file is stored:

Place the dictionary in the installation directory of the tool, the project directory, or in the directory associated with the tool under the user’s profile (%USERPROFILE%\Application Data...).