Tag Archives: C#

Question about generics

In my previous post on Generics, I received a comment from Eddie, who
was asking why developers would want to use the following constraint,
in the example below, when he would pass the parameters as IComparable
interface types.

public static bool IsLessThan(T one, T two) where T:IComparable
return one.CompareTo(two) < 0;

public static bool IsLessThan(IComparable one, IComparable two)
return one.CompareTo(two) < 0;

The previous comment touches on the generics vs base class debate, of which there is pros and cons to both.

Eddie raises an interesting question, and I am giving it some thought.
A few reasons for not using IComparable as the parameter type come to

If you wanted to compare value types, casting to IComparable would
convert the value types to a references by boxing, which is what
generics are trying to avoid.

A reference is 4 bytes in length, so, when comparing two short
values,  Eddie’s example would pass at least 8 bytes across the
stack (+ overhead). Using a generic with Unit16 type would only use of
4 bytes for the two parameters.   

Eddie’s example would require up casting the interface reference type to
known type if the method did more than just compare two values with
CompareTo. The whole point of generics is that the developer of a
generic should not have to know anything about the intended type used
in the generic context. Otherwise, we might as well use cast from
System.Object like ArrayList does.


I forgot to mention in my last post, about Generics, that Sahil Malik helped me out with
the solution. Between the two of us we figured out why parameterized
constructors are not allowed when creating new instances of generic

I would have edited my initial post, but the formatting in my blog that
displays code syntax is not happy when edited a second time in free
text box
(used on the admin page of my blog), and the code gets all
screwed up. I haven’t fixed the link to MSDN magazine in that post for
the same reason.

C# Generics

I’ve been playing around with generics in C# today. Simply put,
generics are akin to templates in C++, only much better. My aim in this
post is not to explain the in’s and out’s of generics, in the new 2.0
version of the .NET Framework but to highlight some key points of

For a primer on generics, read part 1 and part 2 of an article included in MSDN magazine, by Jason Clark.

: So, what’s the point of generics?
A: They provide a mechanism for defining code without specifying variable types.

So, the typical example is the System.ArrayList problem. Let’s say that
you want to store integers in an ArrayList because it offers dynamic
sizing, sorting and the ability to remove random accessed elements from
the collection. The problem is that ArrayList uses a base type of
System.Object to store data – a reference type. Adding an integer to an
ArrayList will involve boxing the integer value type before insertion,
which incurs a large performance overhead. Casting to
System.Object also side steps type checking, so the compiler will not help
you out if there is problem with instances of incorrect types added to
the collection, which means developers have to add their own type
checking code.

Generics provide a neat way to define collection classes
(but not restricted to collection classes), which are type agnostic.
The following example defines two instances of the System.Collections.Generic.List class, one
which contains strings, and the other which contains integers.

List stringList = new List();
List intList = new List();

: How do generics work in the CLR?

In C++, templates are processed by the compiler for each use of the
template. Each template is expanded into a concrete type at compile time when required
by a caller of said template. So, using a single template multiple
times with different types will create a new concrete version of the
template for each type. Misuse of templates in C++ can very quickly cause code bloat.

C++ templates are not compiled or type checked for errors until they
are used. So, the compiler will let you write reams of code, and won’t
compile any of it until it is specifically used as a template

No validation of template code is performed by the C++ compiler. The
example below is a template function to compare two instances of type
‘T’. This function works well when ‘T’ is an integer, but what if ‘T’
is a class type
that does not contain the less than operator? The developer will see
some ambiguous compiler error in the template, not an error indicating
the real problem.

class Foo
int IsLessThan(T one, T two)
return one < two;

Generics deal with both code bloat and type validation checking. Code
bloat is limited because the JIT compiler stores one version of the
common reusable code between template instances. Expansion of generic types is
performed at run-time, all that exists of a constructed type at compile
time is a type reference.

Generics are type and validation checked at compile time using
constraints.  In their bare form (without constraints), generics
don’t enable the developer to do much. The
example below is the C# version of the C++ template above. Compiling
this code will cause an error.  The compiler doesn’t know anything
about type ‘T’ and cannot deduce whether a less than comparison is
legal, so it doesn’t permit it. The same goes for the CompareTo method.
In fact, pretty much the only operations and method calls that can be
performed on a bare generics are those associated with
System.Object – GetType, ToString etc.

public static bool IsLessThan(T one, T two)
return one < two;

Q: So what are these constraints?

The following example is the correct way to achieve the comparison we were looking for above. The where
keyword is followed by the constraints, in this case I have indicated
that ‘T’ must be derived from the IComparable interface, so the compiler knows that
types passed to the generic method can always be compared. 
Constraints aid the compiler in describing what rules can be applied to
parameter types, and can determine the operations and
methods that can be called in generics.

public static bool IsLessThan(T one, T two) where T:IComparable
return one.CompareTo(two) < 0;

Another constraint is new(). This constraint tells the compiler
that the code in the generic method can create new object instances of
the parameter type.  This is especially useful when using helper
classes to construct derived class types.  I ran into this
constraint today when I was developing a utility class.  I was
surprised to find out that the new() constraint only enables
construction of types that have a default non-parameterized
constructor.  At the time I didn’t know why this was so, but I
later found out it is because the compiler cannot evaluate
parameterized constructors without breaking validation
checking.  For example, if ‘T’ is a class, which requires a
parameter passed to the constructor of ‘T’ that is itself complex type, the compiler
has no way of knowing if the generic will work for all different types
bound to ‘T’. The template may work great if ‘T’ is an employee, with
parameterized constructor taking in a name as string, but  would not work if
‘T’ is then an integer.  My example below highlights this

using System;
using System.Collections.Generic;
using System.Text;

namespace Generics
/// Base class, nothing fancy, just stores a name.
class MyBase
string _name = String.Empty;

public string Name
get { return _name; }
set { _name = value; }

public MyBase(string name)
_name = name;

public MyBase()
_name = “no name”;

/// Sub class, says hello.
class MySub : MyBase
public void Hello()
Console.WriteLine(“Hello ” + Name);

/// Utility class.
class Program
/// Create a version of the base class the old way.
public static MyBase NewInstance_Bare(string name)
return new MyBase(name);

/// Create an instance of any class that derives from MyBase.
/// The new() constraint enables the method to create a new instance
/// using the default parameter-less constructor of T.
public static MyBase NewInstance_Template(string name) where T:MyBase, new()
// T instance = new T(name); — this will produce a compiler error.
// The compiler has no way of knowing that all types ‘T’ will have a
// constructor with string as a single parameter.
T instance = new T();
instance.Name = name;
return instance;

static void Main(string[] args)
// No need to store instance as MyBase type and then cast up,
// this is just to show that the helper method will create an
// instance of MySub, which is derived from MyBase.
MyBase instance = NewInstance_Template(“Rob”);

Q: What is inference?

.Net is smart enough to determine the parameter type in a generic if
variable of the same type is passed as to the method as a parameter.
The example code below defines a generic method. When calling this
method, type ‘T’ can be inferred by the parameters passed to the method.

public static bool IsLessThan(T one, T two) where T:IComparable
return one.CompareTo(two) < 0;

static void Main(string[] args)
int a = 1, b = 2;
// ‘T’ is inferred as int because a and b are of type int.
bool result = IsLessThan(a, b);

Suppressing the MODI Popup using C#

For those of you who have never heard of the MODI acronym it stands for
the Microsoft Office Document Image writer, which is a virtual printer
driver for converting printed content into Microsoft Document Images or
TIFF files. The idea for this virtual printer, shipped with Office, is
to provide a means for converting output from applications with
printing ability into a format that can be read by Office applications.

I am working on a project that converts known file formats into TIFF
images, so MODI is ideal for this task. The project involves converting
multiple files at once, using multi-threading. Converting Office type
documents with MODI was easy, Word, Excel, PowerPoint
etc, provide printing ability using a COM API. The method call in these
application interfaces requires a printer name and filename to save to,
if using virtual printers like MODI. Life is good. The problem comes
about when using non-Office applications, such as Internet Explorer,
to print using MODI. The print method in IE’s API does not provide a
way to specify the output file, as with the Office applications, so
during the print request MODI pops up a helpful dialog box – great in a
single thread printing environment, bad in a multi-threaded application
with lots of print jobs.

I scoured the web looking for a quick fix to the MODI pop up problem but
found very little help. Microsoft provides an API for MODI but it is
designed for sending documents to the driver, not manipulating the
driver options. The only helpful hint I came across was to post
or send messages to the dialog window that MODI pops up, thus simulating a user
pressing the “save” button. Using this idea I got to work on writing a
class that would manipulate the MODI pop up window from C#.

I wrote a simple class that will manipulate any instance of  MODI
pop up window that is found on the system. The class uses Win32 API
calls to find the “Save As” window with the same characteristics used
by MODI. Once found I can send Windows messages to the controls on the
form to change the file name location and click the save button.
MODI typically displays the pop up window a short time after a print
request has been made. This time is dependent on the sized of the data
being sent to the MODI printer. Most applications use the spooler to
print to MODI and the print call is asynchronous, meaning the call will
return immediately after spooling before printing starts. It is not
enough to detect the pop up window directly after a print method
because the MODI may still be busy and the pop up will be missed. So I
wrote functionality into my class to wait for an expected MODI pop up
window for a finite period of time.

Below is an example of how to call my class using C#. My class can also
be called from VB.Net, or any other .Net language, only the syntax will
change accordingly.

// Called after a print method invocation.
// Wait 5 seconds for the window to appear.
// If the null is returned no window could be detected.
MODIWindow window = MODIWindow.WaitForWindow(5);
if (null != window)
// Change the filename.
window.Filename = “c:newfile.mdi”;
// Make the window go away by simulating clicking save.

The code for the MODI Window class can be found Here.

Expose a .NET Assembly via COM – without RegASM.exe

I kept promising myself I would write a post on how to expose a .NET
assembly to COM without having to use RegASM.exe. Someone asked me
today for the very code to do this, so I thought now would be as good
as time as any to write my post.

Microsoft provided a wonderful thing when they invented COM Interop.
Most developers know about calling existing COM components from inside
a C# or VB.NET application, but fewer developers know about operating
the system in reverse – calling .NET from VB6 or C++ via COM.

My code, attached below, emulates exactly what RegASM.exe does, but
provides the developer better control over what happens to the registry
and GAC. To successfully expose a .NET class, contained in an assembly, via COM the following things have to happen:

• Said .NET assembly must be added to the GAC (Global Assembly
Cache). There is debate on whether this is true. However, it’s
generally a good idea to install an assembly in a fixed location when
adding registry hooks to that location, and what better place than the
GAC. Non-GAC’d assemblies are liable to break when moved or overwritten
by newer non-backwards compatible versions. The GAC will ensure the
correct version of an assembly is maintained and contained (look, it
even rhymes).

• Registry entries must be added for each exposed class and
interface. Regular COM classes refer to in-proc or out-proc dynamic
link library servers. When exposing a .NET assembly the registry
entries refer to the .NET framework core (mscoree.dll) as the server.
The .NET framework will intercept all COM calls and load the .NET
assembly on behalf of the calling process.

• A type library is to be generated to provide calling applications with a map of exposed interfaces, methods and properties.

The code attached provides all of the above:

Installer.cs – Provides methods to add and remove .NET assemblies to
and from the GAC, and to install and uninstall registry entries.
RegistryValue.cs – Helper class for registry value entries.
TypeLibGen.cs – Helper class for type lib generation.

At the end I have included example code to install and remove
assemblies, as well as what attributes need to be added to a .NE
assembly to make it exportable via COM.

A note on TypeLib generation:

I haven’t been able to find some nice C# code to generate type
libraries from .NET assemblies using reflection, so I had to use the
built in TypeLibConverter method – ConvertAssemblyToTypeLib.
Unfortunately this method doesn’t allow me to specify what classes,
methods and attributes are exported to the type library, it exports all
public classes and types. This can be confusing – the registry may not
contain registry entries for some of these exported types, depending on
how you attribute your code.

To avoid this problem, attribute all public classes and types with
[ComVisible(False)] if not intended to be callable from COM. I show
this in my example at the bottom of the code.

Download code here.

More on Null and Empty Strings

Following on from Jeff Atwood’s post
about comparing a string to empty string (“”), I found out that C# and
VB.net do not behave the same when comparing a string that is null.

In the following C# snippet, the code will display The String is NOT Null:

string s = null;
if (s == “”)
  Console.WriteLine(“The String IS Null”);
  Console.WriteLine(“The String is NOT Null”);

The following VB.net code will display The String IS Null:

Dim s as string = Nothing
If s = “” Then
  Console.WriteLine(“The String IS Null”)


  Console.WriteLine(“The String is NOT Null”)
End If

The IL for the C# code is:

.method private hidebysig static void
            Main(string[] args) cil managed
      .custom instance void [mscorlib]System.STAThreadAttribute::.ctor()
        = ( 01 00 00 00 )
      // Code size       38 (0x26)
      .maxstack  2
      .locals init (string V_0)
      IL_0000:  ldnull
      IL_0001:  stloc.0
      IL_0002:  ldloc.0
      IL_0003:  ldstr      “”
call       bool
      IL_000d:  brfalse.s  IL_001b

      IL_000f:  ldstr      “The String IS Null”
call       void
      IL_0019:  br.s       IL_0025

      IL_001b:  ldstr      “The String is NOT Null”
call       void
      IL_0025:  ret
    } // end of method Class1::Main

The IL for the VB.net code is:

.method public static void  Main() cil managed
      .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =
        ( 01 00 00 00 )
      // Code size       46 (0x2e)
      .maxstack  3
      .locals init ([0] string s)
      IL_0000:  nop
      IL_0001:  ldnull
      IL_0002:  stloc.0
      IL_0003:  ldloc.0
      IL_0004:  ldstr      “”
      IL_0009:  ldc.i4.0
call       int32

      IL_000f:  ldc.i4.0
      IL_0010:  bne.un.s   IL_001f

      IL_0012:  ldstr      “The String IS Null”
call       void
      IL_001c:  nop
      IL_001d:  br.s       IL_002b

      IL_001f:  nop
      IL_0020:  ldstr      “The String is NOT Null”
call       void
      IL_002a:  nop
      IL_002b:  nop
      IL_002c:  nop
      IL_002d:  ret
    } // end of method Module1::Main

As we can see from the VB.net IL, the string comparison is replaced
with a call to
Microsoft.VisualBasic.CompilerServices.StringType::StrCmp. From further
reading I understand that Microsoft did this to maintain compatibility
with VB6. The C# compiler on the other hand uses op_Equality to check
the equality of empty string and null. Since null and empty string are
not equal C# returns false from the condition.

So, the debate about whether to use S == “”
or not just about performance, but also about expected operational
behavior. Developers who switch between C# and VB.net could find some
unexpected results in their software if they are not aware of this

Going back to performance…. Chris Taylor has some nice graphs on
his blog, which show the significant differences in time between S1 == S2, S1.op_Equality(S1), S1.Equals(S1) and String.Equals(S1, S2). Performance varied by test but S1.op_Equality(S1) seemed to be an overall god performer, which is real handy because it’s what the C# compiler chooses when optimizing S1 == S2.

As much as I hate to see code, which doesn’t read as one would expect, VB.net programmers might want to consider using String.Equals(S1, S2) or S1.Length > 0 when doing lots of string comparisons.

In both C# and VB.net worlds, it’s good development practice to check
your strings against null before performing equality operations. Never
assume the compiler is always going to do the work for you – oh it
brings me back to my C++ days when the compiler did crap for you.

Null, Empty Strings and Performance Programmers

Jeff Atwood makes a complaint about “performance programmers” breaking his code.

In his example, Jeff shows the following snippet of code:

If Value <> “” Then
  If nvc.Item(name) = “” Then
    nvc.Add(name, Value)
  End If
End If

… which was then changed to by the performance programmer.:

If Value <> String.Empty Then
  If nvc.Item(name).Equals(String.Empty) Then
    nvc.Add(name, Value)
  End If
End If

The new code now breaks because if the NameValueCollection (nvc) does not have an item in the container with name it’ll return null/nothing, which causes the call to Equals
to fail with a null reference exception. Jeff’s code works because null
references can be compared with empty string in C# and VB.NET.

Comparing null references to empty string is not good programming
practice in general (in C++ such a comparison would cause an
exception). Jeff wrote his code knowing that this comparison was safe
because he knew about the language fundamentals in which he was
developing, the performance programmer did not. This is a good example
of the typical traps that most performance crack teams fall into when
tuning an existing application. Developing software is an art form –
writing good maintainable code that works and performs well sometimes
requires the developer to use non-typical syntax, which can throw other
unfamiliar developers of the code into a loop.

Object References in C#

I have been working with some code written by other developers and it appears that there is some confusion with using the ref prefix on object parameters passed to a function. The following example illustrates some of the code I came across:

using System;


namespace foo


      internal class MyClass


            private int _x = 0;


            public int X


                  get { return _x; }

                  set { _x = value; }




      class Class1



            static void Main(string[] args)


                  MyClass myObj = new MyClass();

                  Foo(ref myObj);




            public static void Foo(ref MyClass instance)


                  instance.X += 5;





Notice the use of the ref object parameter in the Foo method. Many developers make use of ref unnecessarily when they intend to change the content of an object instance passed to a method. 


By default, all parameters are passed by value in C#, which ensures that any changes to parameter values are lost upon leaving a method and the original values passed from the calling context are restored. This is achieved by making copies of values being passed on the stack before calling the method. Adding the ref prefix to a parameter instructs the compiler to write code to pass the address of the variable containing the value instead of the value itself. When in method scope, the compiled code can make changes to the value by implicitly dereferencing the address stored in the parameter.


Unlike C++, C# will not allow a developer to pass an object across the stack.


All object instances in C# are reference types. The following code produces two object references that points to the same object instance. Any changes made to the object using reference A are reflected also through B.


object A = new object();

object B = A;

Since all object instances are references then the myObj object instance, instantiated in the code at the beginning of this post, is a reference and can be passed to the Foo method without the need of the ref keyword. The method can still manipulate the contents of the object because it’s not changing the value of the parameter itself but what the object reference points to. If Foo was required to reassign the parameter to a new object instance then the ref keyword would be required because the object reference change would need to be preserved outside the Method scope.


The ref keyword should similarly be used when a method is to change the value of a primitive type being passed to a method.


The out keyword is similar to the ref keyword in that it allows a change to a passed parameter to be preserved after exiting a method, but out does not require a parameter to be assigned when entering a method. However, out does require a parameter to be assigned before exiting a method.

Free POP3 Client for C#

Announcing FreePOP3 ….


I’ve not had the chance to try this out yet but I plan to. Hopefully it has the feature of leaving messages on the server. Ideally I’d like an IMAP client, but POP3 will work for what I need for now. Anyone know of a free IMAP client for .NET?