C#

VSX Add-in Development Adventures: Window.Object returns NULL

Elroy Dsilva — Sun, 30 Aug 2009 01:01:49 GMT

I’m in the middle of developing an add-in for Visual Studio 2008, a simple one that would help our in-house code review process. If you’ve ever written a VS add-in, you’d know the basic routine – Visual Studio creates the basic class Connect derived from IDTExtensibility2, then you put in your code in the methods OnConnection, OnDisconnection, OnAddInsUpdate, OnStartUpComplete and OnBeginShutdown.

I developed a few user controls (UserControl objects) for showing some UI as tool windows. One of them was AddCommentView which is just a dumb UserControl that displays some textboxes and buttons and also takes in some input. I deployed this control as a separate DLL and linked it to the add-in. Then, as usual, the following code should do the job of creating the tool window.

And like always it worked just fine till I tried to test it and that’s when I realized something wasn’t quite right.

The CreateToolWindow2 method has two outputs – the tool window (which is returned by the method) and the hosted user control (the ref parameter ‘objTemp’ in this case). The hosted user control can also be retrieved through the Window.Object property of the returned tool window. The problem was – no matter what I tried the Window.Object property always returned null and so did ‘objTemp’.

The solution – I was acting dumb, very dumb. Visual Studio requires all hosted controls to be visible to COM. After adding the attribute to the entire assembly using [assembly: ComVisible(true)] , everything started working like a charm (you can apply it even to the individual control if you don’t want to make the entire assembly COMVisible).

C# 3.0 for Beginners - Extension Methods - Part 2

Elroy Dsilva — Tue, 06 Jan 2009 11:32:41 GMT

C# 3.0 for Beginners - Extension Methods - Part 1

Elroy Dsilva — Fri, 07 Nov 2008 06:29:13 GMT

All C# code is eventually executed by the .NET CLR. This requires the C# compiler to transform the LINQ query expressions to a format that is understandable by .NET. LINQ query expressions are transformed into method calls, which are called extension methods. These methods are slightly different from normal methods. Lets discuss them in more detail:

Consider the example that we saw in my previous posts.

public static void GetIExplorer()

{

// 1. Data Source

Process[] processes = Process.GetProcesses();

// 2. Query Creation

IEnumerable<int> query =

from p in processes

where p.ProcessName.ToLower().Equals("iexplore")

select p.Id;

// 3. Query execution

foreach (int pid in query)

{

Console.WriteLine("Process Id : "+pid);

}

The query creation in part two transforms in a series of method calls on the data source 'processes' as follows.

IEnumerable<int> query =

processes.Where(p => p.ProcessName.ToLower().Equals("iexplore"))

.Select(p => p.Id);

The Select clause, however, it not essential. It may be ignored and you might retrieve a list of processes and not their process Ids. The Select clause here specifies the entity to be selected in detail, in the above example, it was the process id belonging to the selected process.

Now, you might wonder that since the Where() method was called on the 'processes' Array, the Array object might have implemented the Where() method. But, that's not quite the case here. The method Where() is called an extension method and is used for extending a type's functionality.

We have also made use of lambda expressions here. We will discuss their significance later in detail, but, for now, you can look at it as if it were a provision to select entities based in certain specified conditions. In the above code the variable 'p' indicates each element in the 'processes' array which is subjected to an expression evaluation (p.ProcessName.ToLower().Equals("iexplore")), and only if the result of the condition evaluation is true, will the item be selected as the result of the query. These are filtering expressions.

In my next post I will describe how to define and use your own extension methods.

C# 3.0 for Beginners - Query Execution in LINQ

Elroy Dsilva — Wed, 05 Nov 2008 08:48:42 GMT

The execution of queries written is different from what a new LINQ user would perceive it to be. The query isn’t evaluated and the result is not stored in the query variable until the foreach iteration (where the values are actually required) or a manual iteration using the underlying GetEnumerator and MoveNext methods. The query variable only stores the query commands. This is concept is referred to as deferred execution.

public static void GetIExplorer()

{

// 1. Data Source

Process[] processes = Process.GetProcesses();

// 2. Query Creation

IEnumerable<int> query =

from p in processes

where p.ProcessName.ToLower().Equals("iexplore")

select p.Id;

// 3. Query execution

// This is the part where the query is evaluated

// and result is stored in the query variable.

foreach (int pid in query)

{

Console.WriteLine("Process Id : "+pid);

}

As the query variable doesn’t store the results, you can execute it as many times as you like. If a data source is updated at regular intervals, you could retrieve the latest results every time you iterate over the query variable.

The figure shown above shows information about the query variable ‘query’. The Results View section shows the results of query execution and it also informs the user that “Expanding the Results View will enumerate the IEnumerable” i.e. perform the query execution for debugging.

Forcing immediate execution of queries
Immediate execution of queries is forced for queries that perform aggregation functions over the data retrieved from query evaluation. These functions include Count, Max, Min, Average etc. These queries execute without an explicit foreach statement because the query itself would use a foreach statement to calculate the result.

The following query returns the number of processes identified as “IExplore.exe”.

// Calculate the number of "iexplore" processes

int numberOfProcesses = query.Count();

Execution results can be cached (if need be) for temporary processing using the ToList() and ToArray() methods as shown below:

// Caching results using ToList() and ToArray() methods.

List<int> queryResult =

(from p in processes

where p.ProcessName.ToLower().Equals("iexplore")

select p.Id).ToList();

Array inferredQueryResult =

(from p in processes

where p.ProcessName.ToLower().Equals("iexplore")

select p.Id).ToArray();

C# 3.0 for Beginners - Learning LINQ - An Overview

Elroy Dsilva — Tue, 04 Nov 2008 10:25:45 GMT

I’m probably quite late to provide an overview on LINQ, which is by now a lot more popular than the time when I actually had started hearing about it.

Well, this is expected to be a series of posts that would help other rookies like me who haven’t yet started learning LINQ yet. So, lets get started. To begin with I’m providing here an overview of LINQ (Language Integrated Query).

LINQ was introduced by Microsoft with the objective to reduce the complexity of accessing and integrating information. With the LINQ project, Microsoft has added query facilities to the .Net Framework that apply to all sources of information, not just relational or XML data. Everyday programmers write code that accesses a data source using looping and/or conditional constructs etc. The same constructs can be written using query expressions that are far lesser in code size. LINQ makes it possible to write easily readable and elegant code. The examples that follow will imply how easily understandable LINQ code can be.

LINQ defines a set of standard query operators that you can use for traversal, filter and projection operations. These standard operators can be applied to any IEnumerable<T> based information source. The set of standard query operators can be augmented with new domain-specific operators that are more suitable for the target domain or technology. This extensibility in the query architecture is used in the LINQ project itself to provide implementations that work over both XML (LINQ to XML) and SQL (LINQ to SQL) data. Lets write some code to understand the query operators in more detail:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Diagnostics;

/// <summary>

/// Using standard query operators.

/// </summary>

public static void GetIExplorer()

{

// 1. Data Source

Process[] processes = Process.GetProcesses();

// 2. Query Creation

IEnumerable<int> query = from p in processes

where p.ProcessName.ToLower().Equals("iexplore")

select p.Id;

// 3. Query execution

foreach (int pid in query)

{

Console.WriteLine("Process Id : "+pid);

}

All LINQ query operations consist of three distinct operations:

Identify the data source
Query creation
Query execution

Calling the method would show you the currently running Internet Explorer processes (their process ids). The heart of the method lies in the following statement of our program.

IEnumerable<int> query = from p in processes

where p.ProcessName.ToLower().Equals("iexplore")

select p.Id;

The expression on the right hand side of this statement is called the query expression. The output of this expression is held in the local variable ‘query’. The query expression operates on one or more information sources by applying the query operators from the standard or domian specific set of query operators. We have used standard query operators here namely where and select.

The from clause select the list of processes which becomes the input for the where operator which filters the list and selects only those elements that satisfy the condition specified with the where operator. The selected elements are then processed by the select operator that determines any specific information selection for each element.

The above statement can also be written using explicit syntax as shown below:

IEnumerable<int> query = Process.GetProcesses()

.Where(s => s.ProcessName.ToLower().Equals("iexplore"))

.Select(s => s.Id);

This form of query is called a method-based query and the arguments to the query operators are called lambda expressions. They allow query operators to be defined individually as methods and are connected using the dot notation. I will deal with lambda expressions in my following posts.

Anonymous methods in C#

Elroy Dsilva — Mon, 03 Nov 2008 10:23:24 GMT

An anonymous method is just a method that has no name. Anonymous methods are most frequently used to pass a code block as a delegate parameter.

Before C# 2.0, the only way to declare a delegate was to use named methods as shown in the example below

// Create the delegate

public delegate void Display(string message);

// Create the method

public static void DisplayOnConsole(string myMessage)

{

Console.WriteLine(myMessage);

}

public static void Main(string[] args)

{

// Here, the delegate is instantiated with the

// method which should be invoked.

Display myDisplay = new Display(DisplayOnConsole);

// Invoke

myDisplay("Hello World!");

}

Then C# 2.0 introduced the concept of anonymous methods.

// Creation of delegate with an anonymous method

Display newDisplay = delegate(string msg)

{

// Anonymous method body

Console.WriteLine(msg);

};

// Invoke

newDisplay("Hello World using Anonymous methods.");

The difference here is quite apparent. Creation of a new method to act as a handler is not required; the delegate itself specifies what should be done when invoked. Anonymous methods reduce the coding overhead in instantiating delegates because you do not have to create a separate method. Specifying a code bolck instead of a delegate can be useful in situations where creation another method might seem an unnecessary overhead.

Some other points to remember:

There cannot be any jump statements like goto, break or continue inside the code block if the target is outside the block and vice versa.
The scope of parameters of an anonymous method is the anonymous code block.
No unsafe code can be used within the anonymous code block.
The local variables and parameters whose scope contains an anonymous method declaration are called outer variables of the anonymous method. In the following code the variable x is an outer variable.

int x = 0;

Display newDisplay = delegate(string msg)

{

Console.WriteLine(msg + x);

};

An anonymous method cannot access the ref or out variables of an outer scope.

C# 3.0 introduces lambda expressions which are pretty much similar to anonymous methods but more expressive and concise. Applications written using .NET Framework version 3.5 and higher should make use of lambda expressions instead of anonymous methods. I will discuss lambda expressions in detail after I start with LINQ (Language Integrated Query) in my following posts.

Did you know the two uses of ‘default’?

Elroy Dsilva — Sat, 01 Nov 2008 07:22:58 GMT

Well, maybe you do and maybe you don’t. And I’m not trying to start a series of posts tagged “Did you know?”, I guess Sara Ford is much better at it.

You’ve used the default keyword in C# as many times as possible in switch statements to indicate the default operation to be carried out. That’s one place where you would normally use the default keyword.

You can also use the default keyword in generic code where it specifies the default value of the type parameter which is null for reference types and zero for value types. In generic programming it is always difficult to guess what default value to assign to a parameterized type T when you don’t know information such as whether T is a value/reference type; if it’s a value type, is it an elementary type or a struct? This is where the default keyword is used to find out the exact default value for the current type. Here is how it would be used:

class MyGenerics<T>

{

public void MyMethod()

{

T myVar = default(T);

//...

int defaultValue = default(int);

}

The default value for reference types is null, for value types is zero and for struct types each member is initialized with it’s default value depending on whether it is a value or reference type.

Conditional compilation in C#

Elroy Dsilva — Sat, 01 Nov 2008 06:55:05 GMT

Programmers need to debug, which sometimes requires identification of points in your program where a programmer would like to insert code that would help him/her to debug his/her code efficiently. A simple example might be inserting a Console.Writeline() call that prints out values or indicates completion (successful or unsuccessful) of the executed part. However, these lines can clutter up the code structure and also needs removal of the debugging code for the release of the entire software.

This overhead is taken care of by specialized methods in C# that help the programmer debug the code without the need to clean up his/her debugging code for the release phase. These methods which are used for debugging are called Conditional methods. The compiler identifies these marked methods and never includes them in the release build.

Well, that’s good enough. But, how do I make a method conditional? .NET provides an attribute System.Diagnostics.ConditionalAttribute (alias Conditional) to achieve this. Let’s look at some code now.

Defining the conditional method

public class MyTracer

{

[Conditional("DEBUG")]

public static void LogThisMessage(string myMessage, int severity)

{

// Write message to screen or a file or ...

Console.WriteLine(" DEBUG MESSAGE : " + myMessage

+" SEVERITY LEVEL : "+severity);

}

The Conditional attribute has been applied to the LogThisMessage() method with the DEBUG conditional compilation symbol. This signals the compiler that the method should be ignored if the conditional symbol DEBUG is not specified.

Using the conditional method

With the Solution Configurations set to Debug mode if you execute the following code, you would happily see the output window shown below.

public static void Main(string[] args)

{

// Some error occured in my code

// Log the message

MyTracer.LogThisMessage("The error 1221 has occured.", 5);

}

Now lets see what happens to our conditional code in the Release mode. To enable Debug or Release mode you have to look for the Solution Configurations selector in your Visual Studio IDE which is shown below.

Change the mode to “Release” and you would see that the conditional code now has disappeared.

We used the predefined DEBUG compilation symbol in our code. You can have your own defined symbols and use them for conditional compilation. You can define custom compilation symbols in Project Properties -> Build tab -> General. Checkboxes have been provided to enable or disable the DEBUG and TRACE symbols.

.NET also provides two classes that provide similar functionality:

System.Diagnostics.Debug
System.Diagnostics.Trace

These classes contain methods that can also be used for debugging if you do not need more specific custom methods.

Covariance and Contravariance in delegates

Elroy Dsilva — Thu, 23 Oct 2008 02:29:05 GMT

If you’ve used delegates while programming you probably know about covariance and contravariance in delegates that provide a degree of flexibility when you match method signatures with delegate types. Read More...

Efficient XML processing

Elroy Dsilva — Thu, 28 Aug 2008 02:13:10 GMT

Nowadays, many developers deal with a lot of XML files everyday. These files can be anything ranging from uses in configuration, documentation, databases where they are used for data sharing, data transport or simplifying platform changes. These files can grow to a very large size and need to be processed in an optimized way.

For example, while reading a configuration file, the module that reads the XML, iteratively reads the XML tag for the current XML Element and decides what processing it then has to do. A relatively large XML file would then contain a lot of different XML Elements(differed by their tags) that need to be checked each time you encounter an XML Element.

A brute force algorithm ro achieve this would be to check for each XML tag by doing a string comparison using an if-else ladder. For now, your XML file contains just three tags - Config1, Config2 and Config3. Your code would look something like this:

class Caller

{

public void Call(string inputValue)

{

// Using the if-else ladder

if(inputValue.Equals("Config1"))

{

Method1();

}

else if(inputValue.Equals("Config2"))

{

Method3();

}

else if(inputValue.Equals("Config3"))

{

Method2();

}

All works well. But, what if the number of XML tags that need to be handled grow each day. You will be handling "Config1" to "ConfigN" in the same way as you have did before - using the if-else ladder. And what if you have no control over the value of 'N'. That is when the processing time for each file increases and a need arises to check the efficiency of the code. String comparisons do take a lot of time and having so many string comparisons can ruin your code in terms of efficiency, maintablility and scalability.

If you try to visualize the above code in terms of a map, you would see that:

"Config1" maps to Method1()

"Config2" maps to Method2()

and so on...

Here's when you know that it would be useful to modify your code to utilize the Hashtable class. Initialize the Hashtable object to store the <key, value> pair as <string, MethodHandlerDelegate> where the string object represents the XML tag input such as "Config1", "Config2" and so on... and the MethodHandlerDelegate is a delegate type that references the method that needs to be called. This can be done using an initializer method such as:

private delegate void MethodHandler();

private SortedDictionary<string, MethodHandler> stringToDelegateDict;

public Caller()

{

stringToDelegateDict = new SortedDictionary<string, MethodHandler>();

}

public void Initialize()

{

MethodHandler handler1 = new MethodHandler(Method1);

MethodHandler handler2 = new MethodHandler(Method2);

MethodHandler handler3 = new MethodHandler(Method3);

AddHandler ("Config1", handler1);

AddHandler ("Config2", handler2);

AddHandler ("Config3", handler3);

// All the handler methods are initialized here in the SortedDictionary.

}

Note that we use a SortedDictionary object here since we are aware of the types of the key and value that might be inserted into the Dictionary. This saves us from doing any unnecessary downcasting which we would need to do if we used a Hashtable.

Using this approach, it can also be decided at runtime that which of the handlers need be present in the dictionary by using the following methods that add or remove a handler from the dictionary.

Now, you can subscribe the handlers only when they will be needed.

// Adding a new handler

public void AddHandler(string inputValue, MethodHandler handler)

{

stringToDelegateDict.Add(inputValue, handler);

}

// Removing an existing handler

public void RemoveHandler(string inputValue)

{

stringToDelegateDict.Remove(inputValue);

}

When you encounter an XML tag now, use just make the same call that you did earlier like this:

Caller c = new Caller();

c.Initialize();

c.Call("Input1");

c.Call("Input2");

However, you change your Call method to have the following implementation.

public void Call(string inputValue)

{

// Get the delegate to the respective method.

MethodHandler mh = stringToDelegateDict[inputValue];

// Make the call.

mh();

}

This definitely makes life simple while dealing with changes in the XML tags, adding handlers for new tags, removing handlers for existing tags and providing the runtime support for the same. Now, any changes occuring to the XML format would need changes in the Caller.Initialize method. Here, the method handlers act as subscribers that can dynamically subscribe/unsubscribe for a particular event.

Now, what if your design says that it needs to call both Method1 and Method2 to handle the tag “Config1”? In case you were using the OrdinaryCaller design, you would handle it something like this:

public void CallModified(string inputValue)

{

// Using the if-else ladder

if (inputValue.Equals("Config1"))

{

Handler.Method1();

Handler.Method2();

}

else if (inputValue.Equals("Config2"))

{

Handler.Method2();

}

else if (inputValue.Equals("Config3"))

{

// The OrdinaryCaller.Call method needs to be changed like this.

Handler.Method3();

}

The problem with doing this is that you need to keep changing the code of the Call() method and also the main disadvantage is that you cannot change the behaviour of the Call() method at runtime.

Here is where the concept of multicast delegates comes into picture. You slightly modify the AddHandler() method to support multicast delegates. This let you have any number of delegate methods as handlers of each tag.

// Adding a new handler

public void AddHandler(string inputValue, MethodHandler handler)

{

// Check if the string key is already available...

if (stringToDelegateDict.ContainsKey(inputValue))

{

// If yes, create a multicast delegate

// and place it back there with the same key.

MethodHandler temp = stringToDelegateDict[inputValue];

temp += handler;

stringToDelegateDict.Remove(inputValue);

stringToDelegateDict[inputValue] = temp;

}

else

{

// else, simply add the handler.

stringToDelegateDict.Add(inputValue, handler);

}

Just call the AddHandler() method to subscribe a new handler and voila! You’ve got another handler working right where you wanted it.

I felt that the above mentioned technique is just a better way of handling large XML files. I’m sure more cleaner options exist to do the same which I’m not aware of. What do you think? What can be a better and more efficient technique to do this?