Creating RCW Interops from ActiveX (OCX) Controls

Many times we need to use ActiveX controls (ocx) developed in VB6 or C++ in our .NET applications. As you might aware of that, we can't directly use ActiveX components in .NET application. So, we need to create wrapper assemblies around the ActiveX components which we call Runtime Callable Wrappers as I have already talked about that in my previous posts. I am not going to discuss details of RCW, but I will show how to generate the RCWs.
 

You can generate RCW in two ways

1. Using Visual Studio

2. Using Tools TlbImp.exe and AxImp.exe.
 

Using Visual Studio to generate RCW:

This is the simplest way of generating RCWs. Then in your project, open the toolbar, right click on it and select 'Choose controls'. Browse the .ocx file and click OK.

 

 

Now open the 'obj' folder present inside the project folder and you will see two interop dlls are generated namely AxInterop.<FileName>.dll and <FileName>.dll. For example, if the control name is MyControl.OCX then generated assemblies will be AxMyControls.dll and MyControls.dll. The prior one contains the visible components of the user control that can be placed on the form. And later one contains the types.
 

 

 

Using Tools to generate RCW:

Above method of generating RCW fulfils most of the times. However, if you want to have some control over how the interops are generated like default namespace, strong naming etc., you can't do much with Visual Studio. However, for that you can use framework tools to generate RCW yourself.

AxImp.exe and TlbImp.exe are two such tools that ship with NET Framework SDK. In fact AxImp.exe alone is sufficient to generate required interops. We will how that works now. Suppose you have an ActiveX control called MyControl.OCX. Open the visual studio command prompt, change the directory to the folder where MyControl.ocx resides and run the below command.

 

AXIMP MyControl.OCX

 

This will generate two interops AxMyControl.dll and MyControl.dll. The default namespace in the prior one will be AxMyControl and default namespace in MyControl.dll will be MyControl. If you want to change the out putfile name to AxInterop.MyControl.dll, you can run the below command,

AXIMP MyControl.OCX /OUT:AxInterop.MyControl.dll

 

This will generate AxInterop.MyControl.dll and MyControl.dll. You can see that when using AXIMP tool, you do not have any control over other interop dll i.e. MyControl.dll. You also do not have control over default namespace name. So, if I want to give your own names say AxInterop.MyControl.dll and Interop.MyControl.dll with custom namespaces say LegacyControls, then I will do it as below:

First generate the interop assembly containign type definitions using TLBIMP tool as below,

 TLBIMP MyControl.OCX /OUT:Interop.MyControl.dll /namespace:LegacyControls

 

If you want the generated assembly to be strong named, you can supply the strong name key file to above command (as below)

TLBIMP MyControl.OCX ... /KEYFILE:MyCompanyKey.snk

 

Now generate the ActiveX interop using AXIMP tool using the above generated RCW,

AXIMP MyControl.OCX /OUT:AxInterop.MyControl.dll /RCW:Interop.MyControl.dll
 

and of course you can sign this assembly just like as explained before.

 

Now you have generated the two interops AxInterop.MyControl.dll and Interop.MyControl.dll with having namespace AxLegacyControls and LegacyControls respectively.

Note: You must register the OCX before you can use the generated interops.

Memory Leaks in .NET Application - Don't let them slip through your eyes.

Before talking about the main topic, I would like to briefly go through the CLR garbage collection mechanism.  When a .NET application is executed, CLR allocates a block of memory which is called managed heap. This managed heap is logically divided among 3 generations - Gen0, Gen1 and Gen2. Usually Gen0 contains the newly created and short lived objects. So, here is a quick view on what happens during garbage collection -

1. Whenever generation 0 gets full, garbage collection occurs. During garbage collection, the garbage collector examines each object in Gen0 to know whether the object is a root. A root  object is one which has a valid reference (or simply the object is still in use). After the root examination, garbage collector collects all non-root objects and frees the memory occupied by them and the root objects which survived the garbage collection are moved to Gen1. At the end of garbage collection, Gen0 will be 100% empty.
2. Now, suppose the application needs more memory than which is available in Gen0. So, Garbage collection must occur which collects objects in both Gen0 and Gen1. Again, the garbage collection starts from identifying root objects in Gen1. All the non-root objects are collected and their memory is reclaimed. The survived objects (roots) will be moved to Gen2. Then Garbage collector collects Gen0 objects as explained in Step1.
3. Sometimes Later the application might require more memory than which is available in Gen0 & Gen1 together. So, the garbage collection must occur on all three generations. So, Garbage Collector starts examining the objects in Gen2. All non-root objects are collected and their memory is freed-up. The survived objects are going to remain in Gen2 only. Then Garbage collector collects Gen1 and Gen0 objects as explained in Step1 & 2.

What is a Memory Leak?

What we can see from the above explanation is that until an object has a root it is going to remain in memory and is always promoted to higher generation. Having this said, let's see what is memory leak.

Consider you have a class which holds a reference to an unmanaged handle as shown below.

class UnmanagedClass

{

         IntPtr handle;

         Int32[] someBigArray = new Int32[200000];  //a dummy array to hold sufficiently large memory.

         public UnmanagedClass()

         {

                 handle = GetUnmanagedHandle(); // consider this method returns an unmanaged handle

         }

}

Then I will create an instance of above class as below,

private void MemoryLeakTest()

{

        for(int i = 0;  i < 1000000; i++)

        {

                String str = new String();

                UnmanagedClass uc = new UnmanagedClass();  //doesn't

        }

}

In the above function, after every loop, both sr & uc become eligible for garbage collection. Suppose, after 5 loops, generation 0 becomes full and GC must run. See that after 5 loops there are 5 string objects and 5 UnmanagedClass objects are created on heap. Garbage collection starts and sees that all five string objects have no roots. So, it frees the memory occupied by the string objects. Then it starts examiniting the Unmanaged class objects. But, each uc object has an unmanaged root. Since GC cares for only managed object but not unmanaged objects, it will not examine the unmanaged handle. Hence, it treats all 5 UnmanagedClass instances to be roots and moves them to Generation1. At this point the generations look like below.

Ultimately Generation0 becomes empty and the loop starts executing again. Now, again after 5 loops Gen0 becomes full and GC occurs. As explained previously, all 5 Unmanaged objects are treated to be roots and they are moved to Generation1. But, there may not be sufficient space in Gen1 to accumulate all objects that survived in Gen0 collection. So, GC has to run on Gen1 as well. Hence, GC starts examining UnmanagedClass objects in Gen1. Again GC sees that they contain a valid handle hence they are moved to Gen2. At this point Gen1 and Gen2 have 5 UnmanagedClass objects each and Gen0 is empty.

In the same way, after another 5 loops, the 5 UnmanagedClass objects in Gen1 will survive GC and moved to Gen2 and Gen0 objects will be moved to Gen1 and the picture looks like below,

You can see that now the generation2 is getting full and it has to be garbage collected. But, again, all the objects in contain an unmanaged handle and they will not be collected at all. Hence, at the next GC, there will be no memory to left in Gen2 to move any objects into it. At this point, you can say that the application is leaking memory.

So, if the application continues to run, at some point of time, there will be no memory left to allocate any objects and CLR will throw OutOfMemoryException and process terminates.

How to avoid Memory Leaks?

• If your class has an unmanaged handle, implement Finalize and Dispose pattern to release the unmanaged handle. This article gives you an overview of Dispose pattern and this page shows you how dispose an unmanaged handle.
• If you are a consumer of a class that implements IDisposable, as a developer, you are responsible for calling Dispose on it. Ensure, all Disposable objects are disposed or at least those objects that do not have finalizers.
• Avoid static collections. You might know that a type loaded in memory is never loaded until the application is shutdown. Since, static members are type members, they are going to stay in the memory always. So, use static members carefully.

I hope you enjoyed reading this article. Happy Programming.

GC.AddMemoryPressure - Working with native resources.

In this writing, I am going to explain how to deal with a situation where an object occupies a large amount of unmanaged memory while consuming very little managed memory. For example, suppose you are using a Bitmap object in your application. The Bitmap application can consume a lot of native memory. But your application just uses the handle to Bitmap which just uses just 4 bytes in 32 bit machines and 8 bytes in 64 bit machines. This means, your application could create several Bitmaps before the garbage collection kicks in. But at the same time, the native memory consumption by the process can increase enormously.

Let me show you an example. In figure A below, I have allocated 2 bitmaps, each of which occupies some big amount of native memory. But you can see that managed heap just containes wrapper to the Bitmaps which occupy very less memory. I will go ahead and create 2 more bitmaps (figure-B). You can see that native memory usage is gradually increasing while there is still enough memory on managed heap. Since, there is enough memory available on the heap, garbage collection doesn't kickin. So, if some more bitmaps are created and garbage collection doesn't occur, then you might run out of native memory which can result in catastrophic failures.

To deal with such problems, System.GC class  provides two static methods - AddMemoryPressure and RemoveMemoryPressure, whose signature is like below.

public static void AddMemoryPressure(long bytesAllocated);

public static void RemoveMemoryPressure(long bytesAllocated);

To know the advantage of these two methods, have a look at the below BitmapObject class. This class is a wrapper around Bitmap. For simplicity, the constructor accepts an image file and constructs a Bitmap.

class BitmapObject

{

    private System.Drawing.Bitmap _bitmap;

    private Int64 _memoryPressure;

    public BitmapObject(String file, Int64 size)

    {

        _bitmap = new System.Drawing.Bitmap(file);

        if (_bitmap != null)

        {

            _memoryPressure = size;

            GC.AddMemoryPressure(_memoryPressure);

        }

    }

       

    public System.Drawing.Bitmap GetBitmap()

    {

        return _bitmap;

    }

    ~BitmapObject()

    {

        if (_bitmap != null)

        {

            _bitmap.Dispose();

            GC.RemoveMemoryPressure(_memoryPressure);

        }

    }

}

Whenever you want to create an instance of System.Bitmap, you can consider creating an instance of above class instead. For instance, I want to create a Bitmap which can have approximately 5MB size. So, I will create an instance of BitmapOject by passing fileName and size as below,

BitmapObject oBitmap = new BitmapObject("c:\\SomePicture.bmp", 5 * 1024 * 1024);

When the constructor executes, it first creates a Bitmap and stores it reference in _bitmap. Then the constructor calls GC.AddMemoryPressure method passing the size (5MB) to it.  This gives CLR a hint of how much native memory is actually occupied by the object. So, though only 4 bytes (or 8 bytes in 64 bit machines) in managed heap, clr assumes that the object actually consumes 5MB. So, suppose Managed heap is of 50MB, then creating 10 instances of BitmapObject makes CLR think managed heap is full and hence it enforces garbage collection. When the garbage collection occurs, the finalizer method executes disposes the bitmap and removes the memory pressure.

CLR Optimizations - String Interning

In my previous post, I explained how the immutable nature of strings can hurt the performance of your application. In this post, I am going to explain how CLR optimizes string handling through a technique called String Interning.

To begin with, let's take a look at below simple program.

static void Main()

{

    String s1 = "tiger";

    String s2 = "tiger";

    //compare the values of s1 and s2

    bool valuesEqual = String.Equals(s1, s2);

    //compare the references of s1 and s2

    bool referenceEqual = Object.ReferenceEquals(s1, s2);

}

When you execute this program, valuesEqual will be true which is expected to be true since both s1 and s2 contain the same value "tiger". What about the value of referenceEquals variable? there is a twist here. You expect referenceEquals to be false because both s1 and s2 are completely different objects and hence their references should be different. But wait, the value of referenceEquals will also be true!

To proceed further, just change the value of s2 to something else say "lion" and run your program. Now, valueEquals is false which is expected. Also referenceEqual is false too. Now, if you are wondoring why referenceEquals was true in first case. The answer is - it was because the result of String Interning, an optimization technique adapted by clr for string manipulation. So, let's understand what is String interning.

When you run your application (say the above program iteself), CLR creates an internal hash table. Initially the hash table will empty. Then, string s1 is created on heap with value "tiger". Now, an entry is made in the hash table where key will be "tiger" and value will be reference to string object created on the heap.

You see that s1 is created on the heap and the address (reference) of the object is stored in hash table for "tiger". Then, the CLR sees the second instruction String s2 = "tiger"; Now, instead of creating a new string object on heap, it first searches the hash table for the key "tiger" and it will defnitely find an entry. This means that a string "tiger" already exists on the heap whose reference is 0x100. Hence, CLR simly stores the reference from hash table into s2. This way, creating of a new object is avoided and thereby saving memory.

Later  if s2 is assigned a different value say "lion", then CLR will first search for the key "lion" in hash table. But it will not find any entry in hash table. Hence, a new String object will be created on heap for "lion". Also, a new entry will be made in the hash table with key being "lion" and value being reference to new object on heap.

Pretty interesting right? By adapting string interning mechanism, CLR efficiently controls the creation of strings. If you think that this feature is quite useful and want to take advantage of it, you can refer MSDN for String class's static methods Intern and IsInterned.

Apart from above said advantanges, this mechanism has also some disadvantages. The additional overhead in creating & maintaining hash table, repeated hash table lookups can hurt the performance of your application. If you think, string interning hurts your application performance, you can turn this feature off by supplying assembly level attribute "CompilationRelaxationAttribute" with value "CompilationRelaxation.NoStringInterning". But there is a catch here. Even if you supply this attribute, CLR may ignore this attribute and use String Interning. So, just be aware of this.

Beware of excessive string objects

Of all the primitive types in C#, string is a special primitive type in the following regard,

1. It is a reference type (class), unlike - other primitive types being ValueType.
2. It is immutable - i.e. once a string is created, it's contents cannot be altered.

Since string is a reference type, a string object must be created on a managed heap which should be garbage collected when the object becomes orphan. This is fine in the sense that at one or other place we can't avoid creating managed objects and all managed objects have to be garbage collected. But, if you look at the second point above which states strings are immutable. Having said this, what if you want to manipulate the string contents (like appending substring, converting to lower case etc.) ? Ofcourse you can do that. But, the original string is never altered, instead, a new string object is created with new value. What does that mean? Take a look at below code.

    string s1 = "Hello World";

    string temp = s1;           // store the reference of s1 into temp

    s1 = "New World";           // modify s1.

 

First I created a string s1 with value "Hello Word". Then I stored the reference of s1 in temp i.e. both temp & s1 are pointing to the same object. You can verify that by calling Object.ReferenceEquals (s1, temp) which will return true if the reference is same. Then I modify s1 to "New World". At this time, I am actually creating a new String rather than modifying the value in s1. You can verify that by comparing contents of temp and s1. So what is the impact of this? Well, to know the impact, see the below code.

 

    string s = string.Empty;

    Stopwatch watch = new Stopwatch();

    Int32 count = 0;

       

    watch.Start();

    while (true)

    {

        s = s + (count++).ToString();

        if (watch.ElapsedMilliseconds >= 1000)

        {

            break;

        }

        //Thread.Sleep (1);

    }

 

When I ran this code on my i3 machine running Windows7, the loop ran approximately 3 million times. Also, Garbage collection (Gen0) ran for 100 times !!! This is really huge impact on the performance. This is because, after every loop, a new string is created and the old reference becomes the candidate for garbage collection. Also, if you look at the average size of string created at every loop - it is 3Mb. If the garbage collection had not occured, just calculate the total memory occupied by all strings in one second. Thanks to GC for avoiding a disaster. When I uncommented the Sleep statement, the GC collection count reduced to 0.1 per second as the number of strings created per second reduced from 3 million to just 300 ! 

 

Above demo clearly states that too many strings in memory is not good. So, what are all the possible ways?

1. Prefer StringBuilder over String in cases involving heavy string manipulations
2. Avoid string manipulations inside a loop at all possible places.
3. Avoid too many class level/ global string fileds.