There are several issues that can prevent trace data being written. Here are a few of that you might encounter.

TraceSource names

If using TraceSource, the name provided to the TraceSource constructor is case sensitive. If the string doesn’t match your configuration exactly, a default TraceSource instance is created rather than the configured one you were expecting.

TextWriterTraceListener

If using TextWriterTraceListener (or XmlWriterTraceListener that derives from it), there are several more issues that can occur.

The yield statement is one of those C# statements that is really powerful but is either not understood or is unknown to most developers. Raymond Chen just posted a very good write up on how the compiler deals with the yield statement.

The Old New Thing : The implementation of iterators in C# and its consequences (part 1)

The great feature that the yield statement brings is delayed execution in iterations. If building a collection of items to iterate through is an expensive operation on either performance or memory, getting individual items as they are requested may be a better design. Using the yield statement means that this is really easy to achieve.

Take the following code for example:

I have been writing up some instrumentation documentation where I have been explaining the use of TraceFilter implementations. I gave an example of creating a TraceFilter that filters trace events from the TraceListener based on the identity of the executing thread. The issue here is that a TraceListener implementation may be writing its data on a different thread to the one that invoked the trace event. I had always assumed that when you create a new thread, the identity of the creating thread is used as the identity of the new thread. There is a lot of danger in assumptions though. While it’s just an example, I needed to prove that my TraceFilter code wouldn’t be invalid if a TraceListener did use threads for its work.

After firing up Reflector, I poked around Thread.CurrentPrincipal code. As expected, the principal is stored in the context data of the thread (LogicalCallContext via CallContext). What was interesting about the code is that if the call context doesn’t contain a principal, it then consults the AppDomain. In the internal AppDomain.GetThreadPrincipal() method, the code runs a switch around a PrincipalPolicy value. I hadn’t come across PrincipalPolicy before so this was an interesting discovery.

A few months ago I did some research into dependency injection frameworks. One of the interesting features provided by many of the DI frameworks was the support for AOP. This is really interesting stuff and great for injecting logging and caching implementations without having to modify existing code.

There are several AOP implementations around (Oren Eini identified seven in this post) and I have always wondered how some of them worked. Unfortunately I never got the time to research it.

Using aspects in .NET - Part 1 is a post by Istvan that just popped up in my feed reader. He describes how to create an AOP implementation using ContextBoundObject and ProxyAttribute classes. I didn’t previously know that combining these types in the .Net framework allows you to override the new statement. This is extremely powerful. I had assumed that this was the method that TypeMock used for creating unit testing mocks, but Oren’s post identifies it as using a profiling API.

I’m working on a new Visual Studio addin that launches a profiling application that in turn runs unit and load tests. I can’t recall how I created the project, but it must not have been by using the addin wizard. When I debugged the addin in another instance of Visual Studio, I got an error indicating that the addin couldn’t be loaded or threw an exception. The additional information it gave was "No such interface supported".

After pulling my hair out for quite a while, the answer was that the AssemblyInfo.cs contained the following:

I have just released the ReSharper Plugins 1.0 in my NeovolveX extensibility project on CodePlex. This plugin formats code as part of the ReSharper code format profiles.

The following is a copy of the Using ReSharper Plugins 1.0 documentation on the project site

Value Type Alias Formatter

The ReSharper Plugins project currently contains a single plugin that provides C# code formatting functionality. This formatting function allows for type declarations to be formatted between their alias type and their CLR type. For example, depending of the format settings defined in a code cleanup profile, bool can be converted to Boolean or Boolean converted to bool.

I’ve written some code that reflections MethodInfo objects from a type using its name and signature. This has been working well and all unit tests have passed, until now.

Consider the following code:

I had a bit of a slipup yesterday. I had a set of changes that I was relating to two different work items. I realised that I really should split up the check-in into two check-ins so that the code files are better related to their work items. What I didn’t do before checking in both changesets was updating the comments of the check-ins before I committed them.

After realising my mistake, I wondered if I could change the comment of a changeset. Thankfully the answer is yes. After finding the changesets by looking at the history in TFS, I was able to simply adjust the comment to be more appropriate to the changeset and click Save. Simple.

I’ve just hit the foreach code coverage issue again in one of my unit tests (see my Code coverage doesn’t like foreach loops post). To ensure that my tests were correctly covering all possibilities, I had to change the foreach loop into a for loop and run the test again.

The issue in this case is that the collection object I was referencing was ConfigurationElementCollection which implements ICollection. Unfortunately, this type doesn’t expose an indexer property. In order to test the code coverage metrics using a for loop, I first had to create an array of the appropriate length and copy across the items across.

After running the test again, I had 100% code coverage. I have now confirmed that the missing blocks in coverage are a result of the foreach statement rather than an issue with my unit test. Now the question is do I remove the additional code and redundant array copy ? The reasons to convert the code back to the foreach loop are:

Here’s a tip for young players. You may find that getting the latest WiX 3.0 beta from here gives you an error saying that you need to have a version of Visual Studio installed that is above the Express edition. I have Team Suite installed, so it should be a problem.

After lots of research, I came across this post which gave me the answer. It wasn’t a problem with the version of Visual Studio that I had installed, it was because latest build published on the SourceForge download page was prior to their support of x64 systems. After downloading the latest build published here, it’s all good.