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

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.

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...).

I came across this post about the direction of ReSharper for VS2008 via a Scott Guthrie post. It is good to hear where ReSharper is going now that VS2008 has been out for a couple of weeks.

I am using VS2008 with a ReSharper beta and for the most part it is working fine. I have read about people having many problems with the beta, but I haven’t had that many issues. I think a buggy ReSharper is certainly better than no ReSharper. I tried going back to VS refactoring and it was so unproductive.

I find it unfortunate that some people are giving the ReSharper team a hard time for not getting a new version out sooner given that VS betas have been around for quite a while. Perhaps they have no idea how much work would be involved in developing and testing something like ReSharper. Maybe they also haven’t heard about work/life balance. Those kinds of negative comments don’t help developers motivation to get the work done.

I am looking forward to the next ReSharper version. Obviously sooner is better than later, but stable and reliable is better than sooner. [:)]

This was an interesting one. I just installed Orcas Team Suite Beta 2. I would have assumed that Team Suite was the complete package. Everything I needed. Nope, not quite. Team Explorer is missing.

To get Team Explorer, you have to run the setup package for Team Foundation Server in order to then install the Team Explorer client software. Does this sound right. Having to run a server installer to get access to client software???