James Wiseman

What’s Going On Here?

I’m currently reading up on Performance Counters in .NET, and have been taking notes on the topic, so I can refer back later.

These are a series of links and facts that I found helped me understand the topic. Most of the information was available on MSDN, so the relevant links are included.

Some Links

Performance counters front page: http://msdn.microsoft.com/en-us/library/w8f5kw2e.aspx

Runtime Profiling: http://msdn.microsoft.com/en-gb/library/w4bz2147(v=vs.110).aspx

Overview

Performance counter can be used for both for reading and writing pre-defined or custom performance counters.

Reading an Existing or Pre-Defined System Counter

To use, simply instantiate an object, set CategoryName, CounterName, and, optionally, InstanceName and MachineName. and then call NextValue().

The following will get us some simple perf stats:

PerformanceCounter PC = new PerformanceCounter();
PC.CategoryName = "Process";
PC.CounterName = "Private Bytes";
PC.InstanceName = "Explorer";
Console.WriteLine(PC.NextValue().ToString());

Creating a Custom Counter.

You might want to create a custom performance counter, for example, you may choose to instrument the number of records returned from a query over time. We could expose this through a performance counter, and monitor it through Perfmon.

To write to a custom performance counter:

1. Create a new CounterCreationData class. We need:
   • Counter Name
   • Counter Help Text
   • Item from PerformanceCounterType enumeration
2. Create a CounterCreationDataCollection and add the CounterCreationData class to it.
3. Create a custom PerformanceCounterCategory counter using PerformanceCounterCategory.Create
   • Category Name
   • Category HelpText
   • Item from PerformanceCounterCategoryType enumeration
   • Our CounterCreationDataCollection intance
4. Create an instance of the PerformanceCounter class.
5. Make the PerformanceCounter instance writeable by setting the ReadOnly property to false
6. Assign CategoryName, CounterName. (Optionally we can set InstanceName and MachineName also).
7. Call, IncrementBy, Increment, Decrement or set RawValue (note, RawValue does not use Interlocked for multithreading)

These bullet points are reflected in the code below:

// 1. Create a new CounterCreationData instance 
CounterCreationData ccd = new CounterCreationData(
    "AAAACounter1", // Counter name
    "AAA Counter Help",  //Counter help text
    PerformanceCounterType.NumberOfItems32); //Counter type

// 2. Create a CounterCreationDataCollection
CounterCreationDataCollection ccds = new CounterCreationDataCollection();
ccds.Add(ccd);

// Code to demonstrate how to delete a category if we need to.
// PerformanceCounterCategory.Delete("AAAA");

// Check to see if our performance counter category if we need to
if (!PerformanceCounterCategory.Exists("AAAA"))
{
    // 3. Create the PerformanceCounterCategory
    PerformanceCounterCategory.Create(
        "AAAA",
        "AAAA Category Help",
        PerformanceCounterCategoryType.SingleInstance,
        ccds);
}

// 4. Create an instance of the PerformanceCounter class
PerformanceCounter PC = new PerformanceCounter();

// 5. Make the counter writable by setting the .ReadOnly property to false
PC.ReadOnly = false;

// 6. Assign the Category name and Counter Name.
PC.CategoryName = "AAAA";
PC.CounterName = "AAAACounter1";

// 7. Set the counter RawValue and increment
PC.RawValue = 0;
for (int x = 0; x < 100000000; x++)
{
    PC.Increment();
    if (x % 100 == 0)
    {
        Console.WriteLine(x);
    }
}

You may get a security exception when you execute the code. This is because the account under which you’re running the code does not have appropriate permissions on you operating system.

In which case, you’ll need to add the following to the application manifest:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
    </requestedPrivileges>
  </security>
</trustInfo>

This gets you around the problem, but may not be the best approach. For more info, consult: What do if you get a  SecurityException. I’d recommend reading it, as there’s more useful info on this with regard to alternative approaches.

Also note that this ensures the application requests privileges when it is run. This doesn’t help us help us when attempting to debug the application. For that, we need to run Visual Studio as an administrator. When I tried it with VS2012 on Windows 8, the application  prompted me about this, and then upon confirmation restarted automatically.

We can now view the new counter in Perfmon. Note, that all the counter and category information is loaded into Perfmon once when you start it up. To pick up any new or modified counters or counter categories, you’ll need to restart the application if  it’s already open.

Different Sorts of Pre-Defined Performance Counters

Out-of-the box

• Exception
• Interop
• JIT
• Loading
• Lock and Thread
• Memory
• Networking
• Security

Performance Counter Types

There are a large number of performance counter types. They are as follows (refer to MSDN for more information)

• NumberOfItems32/64, NumberOfItemsHEX32/64.
  
• RateOfCountsPerSecond32/64
• CountPerTimeInterval32/64
• RawFraction
• RawBase
• AverageTimer32
• AverageBase
• AverageCount64
• SampleFraction
• SampleCounter
• SampleBase
• CounterTimer
• CounterTimerInverse
• Timer100Ns
• Timer100NsInverse
• ElapsedTime
• CounterMultiTimer
• CounterMultiTimerInverse
• CounterMultiTimer100Ns
• CounterMultiTimer100NsInverse
• CounterMultiBase
• CounterDelta32/64

In general, we can break these counters down to five specific types:

1. Average: Measure a value over time and display the average of the last two measurements. Needs a base counter.
2. Difference: Subtract the last measurement from the previous one and display the difference
3. Instantaneous: Display the most recent measurement.:
4. Percentage: Display calculated values as a percentage.
5. Rate: Change in values ovwer time divided by the time period.

Some counters require a base counter. Base counters must be included immediately after the desired counter in the ConterCreationData structure.

There are four base counter types: AverageBase, CounterMultiBase, RawBase, SampleBase. Timers that require a base timer will start with the same text as those timers. For example: AverageTimer32 will require AverageBase.

Performance Counter Category Types

There are three types: Unknown, Single and Multi.

A counter is a single instance upon first creation. When other instances are created it becomes a multi-instance.

I thought I’d share an issue that I encountered recently with dynamic binding in C#, quite simply because I couldn’t easily find a solution out there on the net. In the end, it took the technical genius of a colleague of mine to identify the issue, and provide the solution.

The problem manifested itself when a test project was attempting to test a property on the Class Under Test of type object. At runtime this type was populated with an anonymous type by the Class Under Test.

At this point, it is probably more instructive to conjure a contrived example.

Consider a simple class library:

public class ClassUnderTest
{
    public object GetAnon()
    {
        return new { hint = 1 };
    }
}

Note that we return an anonymous type from the method, implicitly upcasting it to object. The anonymous type is declared within the method within the class, and so is treated by the compiler as internal to the class.

Now let’s consider a simple console application that attempts to access it.

private static void Main(string[] args)
{
    ClassUnderTest c = new ClassUnderTest();
    dynamic d = c.GetAnon();
    Console.WriteLine(d.member.hint);
}

The method GetAnon() of ClassUnderTest returns an object, thus denying us access to the members of the anonymous type. At this point we can access the properties via reflection, or if we’re being lazy (and naughty) set up an identical anonymous type and compare hash codes. (This is not to be encouraged: Principally because different types may generate the same hash, but there are other reasons which are outlined here on StackOverflow: http://stackoverflow.com/questions/16517392/is-it-safe-to-use-gethashcode-to-compare-identical-anonymous-types)

As it is, the solution above uses dynamic typing to achieve this effect. However, when you run it, the program throws a RuntimeBinder Exception:

‘object’ does not contain a definition for ‘member’

This is not a very helpful error message, and gives little clue as to the potential solution.

The problem is that because the anonymous type is internal to the declaring assembly, our client assembly cannot actually access this. To solve this, we have to make the assembly internal visible to the client application, which in this case is the unit test project.

We can emulate this in our sample solution by modifying AssemblyInfo.cs within ClassUnderTest  to contain the following:

[assembly: InternalsVisibleTo("ConsoleApplication1")]

In our real-world project we have to make internal of the Class Under Test visible to the test project.

Just recently, after deploying a web application to a testing environment, I was  approached by one of the testers complaining of an “Out of Memory” exception.

The application in question was a port of a legacy system (written in JSP and C++) from an unsupported Windows 2000 server to a more future-resistant .NET solution on a later, supported, version of Windows Server. Much of the original functionality was to be retained, and this was facilitated by the ability to copy/paste a large chunk of the original code (particularly the client-side JavaScript and static HTML).

However, some areas required developing from the ground up. One of these areas was the code that XML-formatted the data, and performed the XSLT transforms upon it. A particular headache was to get the whitespace recognition and treatment on the .NET platform to work the same as the older JSP system. After hours of trying different settings, in the end I was forced to reformat the underlying XSLT file just to get the screens looking the same. However, I digress…

With most of the major hurdles out-of-the-way, and the application delivered to testing, it was quite a disappointment to find a memory leak as the cause of the “Out of Memory” exception, especially at the scale I was noticing (50K+ per web page post).

I was pretty sure I had cleaned up unmanaged resources as required, but set about my code with a fine tooth comb to see if there was anything I missed. Eventually I fired up perfmon and stepped through the code line-by-line, looking for where significant memory consumption occurred.

I happened to notice significant memory consumption when stepping over the code that loaded the XSLT and performed the transformation (the equivalent to lines 5 and 10 in the sample below)

var xslCompiledDoc = new XslCompiledTransform(true);
//....
//....get myXSLDoc from some XSL file
//....
xslCompiledDoc.Load(myXSLDoc);
//....
//....get xmlSource and instantitate an XmlWriter
//....
//Memory leak on this line!!!
xslCompiledDoc.Transform(xmlSource, xmlWriter)

This restored my ego a little. It looked like the problem might be some side-effect of XslCompiledTransform, and not the result of overly crap code. It also meant that I had pinpointed where exactly the problem lay, even if I didn’t know how to solve it.

As it turned out, no one solution solved the problem, but it did lay bare an interesting problem with the System.Xml.Xsl.XslCompiledTransform .NET class. When executed, this class will take the XSLT that is passed to it, and compile it down to IL. The problem was that when the client application was run in debug mode, both the load and transformation leaked memory.

So here are the steps that I took to seal the leak:

1. XMLWriter Cleanup

Although the leak wasn’t all my fault, I may have been partially responsible. My first action was to correctly ensure that the XmlWriter unmanaged resource wrapper was cleaned up correctly:

using (XmlWriter xmlWriter = XmlWriter.Create(xmlStringBuilder, xmlWriterSettings))
{
    xslCompiledDoc.Transform(xmlSource, xmlWriter);
}

Using using in this context is considered all-round good practice for any class that wraps managed resources and implements IDisposable.

2. Debug Option Off

The first overload of the XslCompiledTransform constructor accepts a boolean parameter indicating whether or not to enable debug information, and therefore be able to debug the stylesheet itself.

You’ll note from my original code that I had this option set to true, which caused the load and transform to leak memory. The fix was to pass false explicitly, although I could have used the default parameterless constructor instead.

3. Caching in Session

The XslCompiledTransform class was designed to be initialised once (i.e. one call to the load function), and for that instance used for the duration of the application.When you think about it, there is little point in performing a compilation of XSLT to IL every occasion, unless the XSLT content itself is variable.

My code contained two static XSLT files, so I chose to cache these stylesheets in session once initialised. Technically, they could have been stored at application level once and their one instance re-utilised for every user. I must confess that this is not an option I considered at the time, but is something I can always revisit if needs be.

4. Release Mode DLL

The new version of the application was to be hosted within existing application infrastructure. Essentially, the port of the old application was to be a new web page within an existing website.

This existing website had been deployed in debug mode. Changing every module of a large website to release mode was not an option, so I moved all the supporting code out into a dedicated DLL that itself could be deployed in release mode on its own.

5. Precompiling XSL

After doing all this however, I was still observing a significant memory leak upon each page post (between 10K and 13K). The memory  leak was now reserved to the transform, but it was still occurring.

The last step, which eventually fixed the issue was to follow the advice set out at the end of this article:

http://blogs.msdn.com/b/xmlteam/archive/2011/09/26/effective-xml-part-5-something-went-really-wrong-outofmemoryexception-and-stackoverflowexception-thrown-when-using-xslcompiledtransform.aspx

Another way to resolve the problem is to compile the stylesheet “offline” (i.e. not at runtime) with the xsltc (xslt compiler, more details in MSDN http://msdn.microsoft.com/en-us/library/bb399405.aspx). This tool will create “regular” assemblies (.dll files) for the Xslt stylesheet and the embedded scripts. To be able to use them in your app you just need to add references. The memory leak problem is resolved – there is no compilation going on at runtime so no temporary assemblies are created.

At the time of writing this was required to be a manual build step. The actions that I tool specifically were to compile each of my XSLT files (input.xsl and output.xsl) into DLLs with equivalent names (InputXSL.dll and OutputXSL.dll) and internal class names (InputXSL and OutputXSL). This was done with the following syntax:

xsltc.exe /class:InputXSL /out:InputXSL.dll input.xsl

Note: the xsltc.exe executable took some finding. The one I needed was located in C:/Program Files/Microsoft SDKs/Windowsv7.0A/bin, however this will be dependent on the .NET framework version you are using. If you don’t have the framework SDK installed then you will need to do so.

Once the DLLs were compiled, I referenced them from the new component I created in step 4 above. This gave the code access to the internal class names just stipulated.

Finally, I updated the code itself to pass the respective stylesheet class to the XsltCompiledTransform load() function:

xslCompiledDoc.Load(typeof(InputXSL));

When this last step was completed, the memory profile of the application remained constant, and there were no observable memory leaks.

Previously I wrote about the The 10 Type Members of C#, and how it would be useful to list and understand each. In this article, I’ll take it a step further and refer to the identifiers and keywords of C# in the same context.

At the time of writing, According to MSDN, there are 77 Reserved Identifiers. These have a special meaning to the and cannot be used as a custom identifier unless they are prefixed with @. For completeness, they are:

Some of these have different meaning depending on the context, for example:

• using
• in
• out

MSDN also lists 23 Contextual Keywords. You can use these words as custom identifiers:

Again, some of these have an overloaded usage, for example:

• partial
• where

In contrast to my suggestion in the aforementioned article 10 Type Members of C#, I wouldn’t suggest that you be able to list them all off the top of your head. However, from a study perspective, I think this list is a good checkpoint of one’s understanding of the C# core. Understanding each one, even if you rarely or never use it, is useful thing.

Continuing on from the last post where we define some custom attributes, let’s look at setting up a class AttributeUsers that will use these attributes.

Add a new class library to the main solution. This library will need to reference the custom attributes assembly.

Here’s the code:

namespace AttributeUsers
{
    [CustomClassLevel]
    public class AttributeUser
    {
        public void Setup() { /* setup actions */ }
        public void Teardown() { /* teardown actions */}

        [CustomMethodLevel]
        public void Message1()
        {
            Console.WriteLine("Message 1 Called");
        }

        [CustomMethodLevel]
        public void Message2()
        {
            Console.WriteLine("Message 2 Called");
        }
    }
}

Again, there’s nothing truly groundbreaking here, however let’s note a few points:

• The class is decorated with [CustomClassLevel]. 
• The class is decorated with [CustomMethodLevel].
• As it’s an attribute, the ‘Attribute’ is implied at the end of the name. We could have said [CustomClassLevelAttribute] instead and got an identical result.
• The methods emit a message to the console. Our goal will be to invoke these dynamically. They are parameterless for simplicity, however later we’ll look at passing data that is specified on the attribute.

You’ll also note the Setup and Teardown methods. Really, this is just a nod to the unit testing framework that we are trying to mimic, and serves no functional purpose. Later on, we’ll see that it’s not enough just to include a library in an assembly – we actually have to use something within it, otherwise the compiler omits it. When searching for assemblies that include attributes, we therefore must have used something in it in order for the Attribute Discovery algorithm to work.

Next up in part 5, we get the nuts and bolts of the attribute discovery, and how we leverage the reflection capabilities to do this.

So, in part 2 we looked at setting up a Visual Studio solution to host the project. We split it up into four parts:

• Attribute Discovery
• Custom Attributes
• Attribute User
• Host executable

In this part we’ll look at our Custom Attributes project. So, if you haven’t already created a solution project then do so now. Create a new Blank Solution under ‘Other Project Types -> Visual Studio Solutions’. When created, add a new C# Class Library to the solution. I’ve called mine JamesWisemanAttributes, but you can name yours in any way you want.

Let’s dive straight into the code:

namespace JamesWisemanAttributes
{
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
    public sealed class CustomClassLevelAttribute : Attribute
    {
        public CustomClassLevelAttribute() {}
    }

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
    public sealed class CustomMethodLevelAttribute : Attribute
    {
        public CustomMethodLevelAttribute() {}
    }
}

We should observe the following things about our code:

• They are simple classes derived from System.Attribute
• The constructor actually does nothing at the moment so could be omitted. (Later it will do something, which is why it’s included here)
• They are themselves decorated with attributes denoting their usage. The class attribute has a Class AttributeTarget and the method’s attribute denotes that it’s for a method only. We could combine these with an or ‘|’ operator.

And that’s really it. There’s nothing groundbreaking about this – we’re just setting up our projects and setting the scene.

Next up, we look at AttributeUser, the class that will use our attribute.

In this post we’ll start looking at the structure of the solution for the problem posed in Part 1.

Recall from the previous post that we were wanting to create a library that could iterate over an assembly looking for types with the attribute [MyClassAttribute] and then invoke methods within that class with the attribute [MyMethodAttribute].

Here’s an example of what this class might look like:

[MyClassAttribute]
public class MyTestClass
{
    [MyMethodAttribute]
    public void MyTestMethod()
    {
        Console.Writeline("MyTestMethod Called");
    }
}

Our end goal is to invoke MyTestMethod dynamically, and see the resulting “MyTestMethod Called” rendered to the console window.

So let’s start by looking at a solution that can support this. I’m using Visual Studio 2012:

Technically, we could host all of the code under one project, but I’ve chosen to split it up into the following^[1]:

• AttributeDiscovery contains the code that will walk our assembly/class/method walker.
• The rather narcissistically named JamesWisemanAttribute contains code that declares our custom attributes.
• AttributeUser is the class that will use the custom attribute, and as such should be picked up by the attribute discoverer.
• HostConsoleApp is the container app for all of this.

HostConsoleApp will reference all three other assemblies. AttributeUser will reference JamesWisemanAttribute. The other projects will reference nothing other than the Microsoft assemblies required for their execution (such as System.Reflection).

It is of particular importance that AttributeDiscovery references nothing. By doing this we are ensuring that it is loosely bound, and not dependent on any particular attribute or code library. That way we can point it at any assembly searching for any attribute.

Now we’ve defined the structure, in Part 3 we’ll start defining some code for our projects…

^[1] Yes, there’s no unit test project. Unit tests are important, and any production-grade code should have a suite of them. This is just a demo, and unit tests would not add to the discussion.

I’m currently studying for Microsoft 70-483 Programming in C# exam, and a strategy I’m trying to adopt when researching for a topic is to combine aspects of other topics that I’m unfamiliar, then writing about them.

This post combines aspects of reflection and LINQ that I’m currently looking at.

• Assembly and Type Discovery
• Late-Binding and Invocation
• LINQ SelectMany and nested selects

I was wanting to write a little ‘attribute discovery’ library that could invoke methods that had been decorated with an attribute [MyMethodAttribute]. The methods themselves would be declared within a class that would also be decorated with an attribute, a different one named [MyClassAttribute].

So, when I include my “Attribute Discovery” library in an executing module, the code should  search though all the assemblies referenced by the module for classes decorated with the attribute [MyClassAttribute]. For any that are found, the code should then search these types for methods decorated with  [MyMethodAttribute].

This might sound familiar.  In fact, we encounter this pattern of attribute usage within unit test projects. Consider a simple test class:

[TestClass]
public class MyTestClass
{
    [TestMethod]
    public void MyTestMethod()
    {
    }
}

How does the framework run this? Well, without delving in and disassembling the code manually, I can’t say for sure, but I can speculate that some sort of process similar to that outlined above is used.

So, how might we achieve this ourselves? Well, that’s what we’re going to delve into in this series of articles, all under the tag EduAttrDiscover.

Up next, we setup our reference project…