Oddity with yield statements

I noticed some interesting display names for some stubbed functions I had which only contain "yield break;" statements.

An overloaded method with the following signature: public IEnumerable Search (IEnumerable keys) appears as: d__0 in the tree view within NCoverExplorer.

I also have a: public IEnumerable Search () which properly appears as: Search (0%)

That being particularly odd, I checked the Coverage.XML file, and found what I think is the underlying problem.

There was the expected: <![CDATA[]]> <![CDATA[ ]]> <![CDATA[]]>

However, there was some additional XML I was not expecting. If the above search method appears in namespace N under generic class C, the search method shows up as follows:

<![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[ ]]> <![CDATA[ ]]> <![CDATA[ ]]> <![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[ ]]> <![CDATA[ ]]> <![CDATA[]]> <![CDATA[]]> <![CDATA[]]>

I can only assume this is because the yield break statement is causing .NET to create a new Iterator for me, and NCover is picking up on that. For some reason, the explorer is blowing away the proper method overload and replacing it with the name of the generated Iterator class. As a result, no coverage information is provided for the method overload and no syntax highlighting exists.

Replacing the yield break with a simple return null instead is sufficient to fix the display. However, I wonder what will happen when I finally get around to fleshing-out the method and (potentially) re-insert some yield statements.

BTW, a preview function on the forum might be nice :)

edit: While not pretty, CDATA tags at least allowed me to include the exact XML, line-by-line so as to prevent the linefeeds from displaying as BR tags. Not being a web dev, I couldn't think up a better method on short notice.

RE: Oddity with yield statements

Avatar,

I've taken the liberty of elevating your post to a support request. We will look at this issue and email you when a fix is available.

Stephen