Living .NET... : .NET

A simple MSMQ Listener helper class

Manoj G — Mon, 17 Oct 2005 01:00:00 GMT

MSMQ simply provides wonderful capabilities when it comes to building asynchronous messaging based applications. You typically run into situations where two applications exchange messages through a queue – one application sends messages to a known MSMQ destination and the other application “listens” to this queue and picks messages up as and when they arrive. The application which listens usually is a windows service which either has a dedicated thread making a blocking call on the Receive method or uses a timer of sorts to periodically check the queue for new messages. Either ways, to maximize throughput, you need to write the queue-listener code in such a way that you can have multiple threads simultaneously processing different messages that arrive at the queue.

MSMQ triggers provide one such solution where we can associate incoming messages to a COM component, based on certain rules, which can be application specific. MSMQ triggers are pretty powerful and also easy to administer. But there is one constraint, which has to do with the fact that only COM components are supported in this scheme, or in other words, message processors should be COM components. In a way, it isn’t that bad a choice after all. You still can create a CCW for a managed class and register the trigger. But, somehow, I didn’t like doing this.

To circumvent this problem, I decided to write a C# helper class, which doesn’t really do anything much, but helps realize a simple multithreaded job (message processing) dispatcher. The helper itself doesn’t do any message processing as such; whenever a message arrives at a queue, it just fires an event (on a new thread pool thread) with the message contents being in the event arguments.

public delegate void MessageReceivedEventHandler(object sender, MessageEventArgs args);

public class MSMQListener
{
    private bool _listen;
    private Type[] _types;
    private MessageQueue _queue;

    public event MessageReceivedEventHandler MessageReceived;

    public Type[] FormatterTypes
    {
        get { return _types; }
        set { _types = value; }
    }

    public MSMQListener(string queuePath)
    {
        _queue = new MessageQueue(queuePath);
    }

    public void Start()
    {
        _listen = true;

        if (_types != null && _types.Length > 0)
        {
            // Using only the XmlMessageFormatter. You can use other formatters as well
            _queue.Formatter = new XmlMessageFormatter(_types);
        }

        _queue.PeekCompleted += new PeekCompletedEventHandler(OnPeekCompleted);
        _queue.ReceiveCompleted += new ReceiveCompletedEventHandler(OnReceiveCompleted);

        StartListening();
    }

    public void Stop()
    {
        _listen = false;
        _queue.PeekCompleted -= new PeekCompletedEventHandler(OnPeekCompleted);
        _queue.ReceiveCompleted -= new ReceiveCompletedEventHandler(OnReceiveCompleted);

    }

    private void StartListening()
    {
        if (!_listen)
        {
            return;
        }

        // The MSMQ class does not have a BeginRecieve method that can take in a
        // MSMQ transaction object. This is a workaround - we do a BeginPeek and then
        // recieve the message synchronously in a transaction.
        // Check documentation for more details
        if (_queue.Transactional)
        {
            _queue.BeginPeek();
        }
        else
        {
            _queue.BeginReceive();
        }
    }

    private void OnPeekCompleted(object sender, PeekCompletedEventArgs e)
    {
        _queue.EndPeek(e.AsyncResult);
        MessageQueueTransaction trans = new MessageQueueTransaction();
        Message msg = null;
        try
        {
            trans.Begin();
            msg = _queue.Receive(trans);
            trans.Commit();

            StartListening();

            FireRecieveEvent(msg.Body);
        }
        catch
        {
            trans.Abort();
        }
    }

    private void FireRecieveEvent(object body)
    {
        if (MessageReceived != null)
        {
            MessageReceived(this, new MessageEventArgs(body));
        }
    }

    private void OnReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
    {
        Message msg = _queue.EndReceive(e.AsyncResult);

        StartListening();

        FireRecieveEvent(msg.Body);
    }

}

public class MessageEventArgs : EventArgs
{
    private object _messageBody;

    public object MessageBody
    {
        get { return _messageBody; }
    }

    public MessageEventArgs(object body)
    {
        _messageBody = body;

    }
}

As you can see, the helper class is indeed simple. One thing to notice though is that, I switch to BeginPeek if the queue is transactional. The reason behind this is there is no overload of the BeginRecieve method that takes a MessageQueueTransaction object and the MSDN documentation also explains the same. The workaround is to use BeginPeek and then do call Receive (synchronous/blocking operation) in the EndPeek method.

At this point of time, this class does not provide much control to the consumer. For instance, it does not allow you to set the maximum number of concurrent threads that can be processing messages - This class queues as many jobs as that supported by the .NET Thread pool. Also, I haven’t tested this code in all scenarios – I have not seen if this works well in the context of a distributed (DTC based) transaction. I shall update this version every now and then to make it more powerful and to work seamlessly in all scenarios.

Patterns in .NET : Citing the Chain of Responsibility pattern

Manoj G — Fri, 30 Sep 2005 03:24:00 GMT

Chain of Responsibility basically involves “chaining” a set of objects between a sender and receiver, where each object in the chain does some processing on the message that is sent between the sender and the receiver.

In the .NET Framework, one area where this pattern manifests is the Remoting infrastructure. In Remoting, a remote method call actually translates to a message exchange between the client and the server. When the message passes between client and the server object, it goes through a series of message sinks, which are objects which implement the IMessageSink interface. Here’s how the interface looks like (attributes have been elided for clarity):

public interface IMessageSink
{
      IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink);

      IMessage SyncProcessMessage(IMessage msg);

      IMessageSink NextSink { get; }
}

The important thing to notice here is that each message sink has a reference to the next sink in the chain. Each sink forwards the message to the next sink in the chain and the last sink to handle the message would be the StackBuilderSink. The client and the server are actually unaware of the intermediate processing; the remote call appears no different from a local (intra-appdomain) call. This scheme forms the basis of the Aspect framework built around the ContextBoundObject. In fact, I suppose, all aspect frameworks would eventually use a realization of the Chain of Responsibility pattern.

PS: It has been quite a while since I posted on patterns topic and I apologize for that.

Manual ADO.NET Transactions and TLS

Manoj G — Mon, 19 Sep 2005 00:24:00 GMT

I have come across several business and data access layer components which have method overloads taking in SqlTransaction (or IDbTransaction) references. The need here is to facilitate ADO.NET manual transactions, where database operations scattered across several components would need to be enlisted under the same transaction. Let’s assume for now that we do not want to avail the automatic transaction services of Enterprise Services or the DTC; performance being one reason, the unavoidable need to derive from System.EnterpriseServices.ServicedComponent being another. The obvious pain in the manual transaction scheme in our case is the leakage of ADO.NET objects (SqlTransaction) into the Business layer, which ideally, shouldn’t be dealing with ADO.NET specific objects at all.

So, what could be the solution to this problem? I thought TLS (Thread Local Storage) could be put to good avail in this case. My idea involves the following steps:

1) Create a helper class (call it TransactionUtils) with BeginTransaction, Commit and RollBack methods which do the work of opening and closing connections and storing transaction (SqlTransaction, for example) objects in the current thread’s named data slot. This helper would be used by the business component which forms the root of the transaction.

2) Change the data access helper (or the DAAB) to check the current thread’s slot for a transaction object and use it if it exists (append the current transaction to to the command object). You could consider creating overloads which are ‘TLS aware’.

This is what TransactionHelper would look like:

  public class TransactionHelper
    {
        // To ensure TransactionHelper is not instantiated. All methods are static
        private TransactionHelper()
        {
        }

        // Name of the TLS data slot.
        private const string TLS_SLOT_NAME = "IDbTransactionDataSlot";

        // Returns a boolean value which indicates
        // whether current thread is in a transactional context
        public static bool IsInTransaction()
        {
            return (GetTransactionFromContext() != null);
        }

        // Begins an ADO.NET transaction with the specified isolation level.
        // Creates a TLS data slot where the transaction object would be stored
        public static void BeginTransaction(IsolationLevel isolationLevel,  string connectionString)
        {
            //To clear off the transaction slot, if in use
            FreeResources(GetTransactionFromContext());
            IDbConnection conn = GetConnection(connectionString);
            IDbTransaction trans = conn.BeginTransaction(isolationLevel);
            LocalDataStoreSlot slot = Thread.AllocateNamedDataSlot(TLS_SLOT_NAME);
            Thread.SetData(slot, trans);
        }

        // Begins an ADO.NET transaction. Creates a TLS data slot where the
        // transaction object would be stored
        public static void BeginTransaction(string connectionString)
        {
            //To clear off the transaction slot, if in use
            FreeResources(GetTransactionFromContext());
            IDbConnection conn = GetConnection(connectionString);
            IDbTransaction trans = conn.BeginTransaction();
            LocalDataStoreSlot slot = Thread.AllocateNamedDataSlot(TLS_SLOT_NAME);
            Thread.SetData(slot, trans);
        }

        // Commits the current transaction and frees the TLS data slot
        public static void Commit()
        {
            IDbTransaction trans = GetTransactionFromContext();
            IDbConnection conn = trans.Connection;
            trans.Commit();
            conn.Dispose();
            FreeResources(trans);
        }

        ///

/// Rolls back the current transaction and frees the TLS data slot
///

        public static void Rollback()
        {
            IDbTransaction trans = GetTransactionFromContext();
            IDbConnection conn = trans.Connection;
            trans.Rollback();
            conn.Dispose();
            FreeResources(trans);
        }

        // Gets an IDbTransaction object from the TLS
        internal static IDbTransaction GetTransactionFromContext()
        {
            LocalDataStoreSlot slot = Thread.GetNamedDataSlot(TLS_SLOT_NAME);
            return Thread.GetData(slot) as IDbTransaction;
        }

        // Disposes the transaction and clears the TLS slot
        private static void FreeResources(IDbTransaction trans)
        {
            if(trans != null)
            {
                trans.Dispose();
            }
            Thread.FreeNamedDataSlot(TLS_SLOT_NAME);
        }

        // Gets a connection object
        private static IDbConnection GetConnection(string connectionString)
        {
            IDbConnection conn = SqlHelper.GetConnection(connectionString);
            conn.Open();
            return conn;
        }

    }

So, the snippet of a business component which uses the TransactionHelper would look something like:

class MyBizComp
{

    public void DoSomeOperation()
    {
        try
        {
            TransactionHelper.BeginTransaction(connectionString);
            // Call other biz components, they would get enlisted within
            // the same transaction
            TransactionHelper.Commit();
        }
        catch
        {
            TransactionHelper.Rollback();
        }
        finally
        {
            // Cleanup
        }
    }
}

So, we have a solution here, which is not that elegant, but atleast, sheilds the business layer from the nuances of ADO.NET. Note that the assumption here is that all the other business components eventually call those methods in the data access layer which are context (TLS) aware.

Two important things to note regarding this approach:

1) The connection is kept open (behind the scenes) during the period between the BeginTran and Commit, and therefore during the execution of all the business components that are enlisted in a single transaction. So, it is imperative to keep transaction bracket as small as possible to improve concurrency.

2) This methodology does not work in a multithreaded scenario, where different components in the call chain happen to execute on different threads. Obviously, because TLS is thread specific.

Another similar implementation you may want to look into is the transaction helper in Juval Lowy’s site, IDesign.Net, where you have a helper class which does something similar, but wraps Enterprise Services.

Come .NET 2.0, System.Transactions provides an elegant way to “scope” a transaction in the business layer. Not so surprisingly, the current transaction (Ambient transaction) is persisted in the TLS. System.Transactions is one of the coolest new things in .NET 2.0 and will be the subject of another post altogether.

Tip: Embedding Resources in Assemblies

Manoj G — Wed, 18 May 2005 15:01:00 GMT

[Problem]: Many a times, you end up using large string constants (usually placed in text files) in your application code. Typical examples are XSLT templates, SQL scripts and so on. It doesn’t really look nice to have a string constant defined in a class which have a hundred lines of text to serve this purpose. You wouldn’t want to store them separately in external text files either, as you wouldn’t want users to see/edit the contents.

[A Solution]: One way to solve this issue is to embed the text file contents in the assembly as a resource and then extract them at runtime. To embed strings in the assembly, you can add the text file to the project, and in the properties of the file select “Embedded Resource” as the build action. Then, to extract the contents of the file from the assembly, you can call the GetManifestResourceStream method on the Assembly instance, and read the stream into a string variable conveniently using StreamReader. You are just done!

Of course, this method is justified if the strings you embed are quite large (say, at least a 1000 characters or so). Else, be happy to use class constants.

Patterns in .NET: Citing the Strategy pattern

Manoj G — Mon, 04 Apr 2005 20:17:00 GMT

Strategy is a quite frequently used pattern. Strategy pattern involves "defining a family of algorithms, encapsulating each one, and making them interchangeable. Strategy lets the algorithm vary independently from clients that use it."

Essentially strategy entails creating an abstract class or an interface abstracting the family of algorithms to be used. I must say that there are umpteen applications of this pattern within the BCL. Let's examine one of them here:

IComparer is an interface defined in the System.Collections namespace and defines a method that can compare two objects. It's primary purpose is to provide a way to customize the sort order of a collection, which is required in the Array.Sort and Array.BinarySearch method implementations. So mapping this to the Strategy (refer to the link above for the class diagram of the pattern):

Icomparer Interface : Strategy, Array class : Context

On similar lines, another citation would be IListSource / IList, which is used in data binding in Webforms/Windows forms.

I will leave it as an exercise to the adept .NET Fx developer to just add plenty more to this list!

Patterns in .NET: Citing the Command Pattern

Manoj G — Sat, 02 Apr 2005 04:10:00 GMT

Of late, I am getting more and more interested in Design Patterns. As Allan Shalloway, in his most excellent book, Design Patterns Explained explains, design patterns are a great way to understand Object Oriented Programming better. Though design patterns are not restricted to the seminal work from the GOF, they do provide a solid basis on how patterns, in general are conceived. I understand that there are umpteen books and resources on patterns, especially those in C# and VB.NET. What I am trying to do here try to cite certain patterns that exist with the BCL, albeit not clearly visible, and also reflect certain problem-solution pairs that we are all way too familiar with, but don’t classify them as patterns. Let me start with an interesting problem we face quite often:

You need to execute a method asynchronously. Now, the Thread and the ThreadPool class allow you to do that, but there is a catch. They accept only specific types of delegates - ThreadStart and WaitCallback respectively. Therefore, you cannot asynchronously call methods with arbitrary signatures directly. So, what's the solution? The answer is Command Pattern. Essentially, in this pattern, you encapsulate the command/operation to be executed as an object, with the method parameters represented by the state of command object. So, to apply the command pattern to our problem, we would need to create a command class that can execute any method, irrespective of the signature. The best way to handle this is by using Delegate.DynamicInvoke method. Therefore, the state of our Command object would contain a delegate instance and an object array, which is passed to the DynamicInvoke method and also, optionally, a result object. Here's how:

public class Command
{
    private readonly Delegate _target;
    private readonly object[] _args;
    private object _result;

    public Command(Delegate d, object[] args)
    {
        _target = d;
        _args = args;
    }

    public void InvokeCommand()
    {
        _result = _target.DynamicInvoke(_args);
    }

    public object Result
    {
        get { return _result; }
    }
}

Now, to execute this command/operation asynchronously, we can use the Thread/ThreadPool class. Given below is a helper that wraps the ThreadPool class. All you need to do is call the static method Invoke passing it an instance the command object. Once again, this command object represents the job to be executed. Note that the Command object is passed as a state object (second parameter) to the QueueUserWorkItem method.

//Just a wrapper to the thread pool class
public class ThreadPoolHelper
{
    private static WaitCallback dynamicInvokeShim = new WaitCallback(CommandInvoker);

    private static void CommandInvoker(object o)
    {
        Command command = (Command) o;
        command.InvokeCommand();
    }

    public static bool Invoke(Command command)
    {
        return ThreadPool.QueueUserWorkItem(dynamicInvokeShim, command);
    }
}

Now let's see how the Command is used (the 'Receiver'). Shown below is a totally arbitrary class using the command:

public class MyClass
{
    private delegate int AddDelegate(int a, int b);

    public void TestCommandPattern()
    {
        Delegate dlg = new AddDelegate(Add);

        //Command to invoke the add operation
        Command command = new Command(dlg, new object[] {5, 5});
        ThreadPoolHelper.Invoke(command);

        //Command to invoke the do nothing operation
        command = new Command(new ThreadStart(JustDoIt), null);
        ThreadPoolHelper.Invoke(command);
    }

    //Sample method
    private int Add(int a, int b)
    {
        return a + b;
    }

    //Sample method
    private void JustDoIt()
    {
        Console.WriteLine("Nothing!");
    }
}

Now, many of you would be ready to pounce on me with the suggestion that BeginInvoke/EndInvoke combination on the delegate offers a similar solution, perhaps more cleanly & efficiently. Well yes, I do agree. I gave the above example as a good illustration of the command pattern and moreover, this method is still apt if you employ the Thread class (Note the BeginInvoke involves a threadpool thread)

In my subsuquent posts, I shall try to cite more such application of patterns in .NET. If there are better examples, or if my citations are flawed in any way, please feel free to drop in your comments. Thanks!

Stream Quips & Traps

Manoj G — Tue, 22 Mar 2005 19:19:00 GMT

I was working with SoapExtensions and my project involved a lot of reading and writing to streams (Yes, in the ProcessMessage method of the SoapExtension). I came across this good article by Jon Skeet which explains the reading of binary data from the stream. This article basically explains the best ways of using the Read method of the stream and also mentions about the potential errors that might creep up when Stream.Read is used incorrectly. A related task is to copy the contents of one stream to another. Here's one of the ways of doing this:

static void CopyStream(Stream inStream, Stream outStream) {
    byte[] buf = new byte[1024];
    int size = 1024;
    int count = 0;

    count = inStream.Read(buf,0,size);
    while (count > 0) {
      outStream.Write(buf,0,count);
      count = inStream.Read(buf,0,size);
    }
    outStream.Flush();
}

A more simple looking helper would involve the StreamReader and the StreamWriter as shown here:

static void CopyStream(Stream from, Stream to)
{
   TextReader reader = new StreamReader(from);
   TextWriter writer = new StreamWriter(to);
   writer.WriteLine(reader.ReadToEnd());
   writer.Flush();
}

Of course, if you 'reflect' the implementation behind these, you would find them to be very similar to the first CopyStream method. What is evident from this example is that it is definitely easier to use StreamReader and StreamWriter over using Stream directly. Also, you can work with strings directly as against using a byte array.

I shall conclude this post by mentioning a few traps that one can usually fall into while using the Stream class. By definition, a stream is plainly, a sequence of bytes. The stream is read from start to finish in a serial fashion (unless you do a seek operation) and the Position property provides the position where the current byte has to be read. Therefore, any operation involving the reading of the entire contents of the stream (like StreamReader.ReadToEnd, for instance) would shift the position past the last byte read. So, reading the stream without resetting the position to zero causes erroneous behavior (I tried to load an XmlDocument using the Load method and I constantly kept getting "Root Element missing error"!)

Another aspect to keep in mind is that most streams (MemoryStream is an exception) are buffered. Writing data to the stream does not mean that the data is transferred to the underlying media or device. We would need to call the Flush method to ensure the same. Again StreamWriter provides an AutoFlush property which can be used when buffering semantics are not really required.

Happy 'Stream'ing!

Contexts & Interception revisited

Manoj G — Fri, 18 Feb 2005 21:23:00 GMT

I have always been awed by the concept of Interception and Aspect Oriented Programming (AOP), especially after having seen and used COM+ Services. In very, very simple terms, AOP is about taking concerns or common aspects in the code (like Concurrency, Instrumentation, Security, etc), factoring them out, and weave them into the application in ways which do not create undue coupling. Interception is just a way of realizing AOP.

The very fact that .NET provides an extensible framework for implementing your own interceptors is an exciting prospect. I would have loved to explain the whole framework myself, which mind you, is undocumented. But then, I came across some great resources, which I'll just go ahead and mention instead:

Also, make sure you give these books a good reading:

Essential .NET – Volume 1, Don Box (Chapter 7)
Advanced .NET Remoting – Ingo Rammer (Chapters 7, 11)

Dabbling with the framework that allows you to pre and post process method calls can lead to interesting thought processes and implementations. Quite a while back, I found this great article - Declarative Transactions using ADO.NET and without Enterprise Services which showed how declarative (automatic) transactions could be envisaged around ADO.NET transactions. But the problem with the code sample was that it actually did not enlist SQL commands under a single transaction. What was really required was a context-sensitive SqlHelper class. This is were I thought I could get my hands dirty with ContextBoundObject and the like. I took the basic idea from the article forward and wrote a simpler version of the context attribute, sink and property classes. What I do here is store a SQLTransaction object as a context property and have the sink do the opening/closing of the connection, calls BeginTransaction & Commit/Rollback. Of course, the implementation does not bear the complete semantics of COM+ DTC based transactions, and hence can be viewed from the academic perspective.

I must say that code is shabby, does not have inline documentation and may require some sprucing up. Moreover, I have only made the ExecuteNonQuery method context sensitive (it is called ContextExecuteNonQuery). The remaining methods would simply need to follow suite. The entire code can be downloaded here. I apologize for not giving a comprehensive explanation, but I shall do it later sometime.

It is really interesting to know where & how aspects can be applied in real-world problems. One place that immediately occurs to me, is Logging and Instrumentation. Juval Lowy, author of the most excellent book - Programming .NET Components presents an excellent sample which can be download here. For other areas where interception can be of value, it is worth-while to look at COM+ services itself. Automatic Transactions, Security (Authentication and Authorization), Synchronization to mention a few.

Singleton applications

Manoj G — Fri, 21 Jan 2005 02:26:00 GMT

I think it is a fairly common requirement to develop applications such that only a single instance runs at a time. This is where Mutexes, an inter-process thread synchronization primitive comes into picture. This is one good example where no other WaitHandle, but Mutexes only can be employed. For the implementation details, you can refer to Jon Skeet's most excellent C# FAQ.

I believe another way is to check if Process.GetProcessByName(“<<App Name>>“) returns a non-empty array. This approach may work fine, but I don't seem to like this personally.

Come Whidbey, you need not bother about using any of the above methodologies, as this is as easy as setting a project property!

Path and Environment: Truly useful classes

Manoj G — Thu, 16 Dec 2004 20:19:00 GMT

I always remember doing painful string manipulations on a file path string, either to extract the drive, the file name or the extension bits from the string in VB6. Things are definitely better in .NET. The System.IO.Path class basically abstracts the way a path string is structured and provides a set of simple helper methods which also absolves a developer from knowing things like the directory separator character, Volume separator character and so on. Saravana, a good friend of mine, explains more on this in his article.

Another really useful class is System.Environment, whichs comes packed with plentiful handy functions to get environment information like environment variables, system directory, etc etc. Check this MSDN link for a complete listing.

Really useful, I must say.

Xpath Expressions and XPathNavigator to the rescue

Manoj G — Fri, 10 Dec 2004 07:03:00 GMT

I would like to admit that I have, many a times, taken XML handling for granted and have come with ghastly pieces of code like the one shown below, where all I need is to find out the number of nodes in an Xml document. What I am doing here, is loading the Xml data it to a DOM, creating a node list and then accessing its Count property - all in all, an extremely expensive and needless process.

booksDoc.LoadXml(booksXml);

int numBooks = booksDoc.SelectNodes("bookstore/book").Count;
for (int i = 0; i < numBooks; i++)
{
// Some code
}

A much better and more efficient way to solve this problem is to use XPath Expressions and the XPathNavigator class. The XPathNavigator provides a method called Evaluate which can evaluate Xpath expressions to return boolean, string, int values accordingly. As an alternative to the above code, we can just use the count Xpath function to return the number of nodes in the node-set.

XPathDocument xpathDoc = new XPathDocument(reader);
XPathNavigator navigator = xpathDoc.CreateNavigator();

int numBooks = Convert.ToInt32(navigator.Evaluate("count(bookstore/book)"));

for (int i = 0; i < numBooks; i++)
{
//Some code
}

The reason why the latter approach is efficient is that XPathDocument creates a read-only in-memory tree that is optimized for Xpath and Xslt. On the other hand, XmlNode is a modifiable DOM representation, which could make it inefficient for Xpath-like scenarios.

An example from Aaron Skonnard's Xml Files column illustrates this better. What the code sample is trying to do is find the sum price of invoice line items from the given Xml document.

The XmlDocument approach:

const string EXPRESSION = "/Invoices/Invoice/LineItems/LineItem/Price/text()";

static void UseDOM()
{
    XmlDocument doc = new XmlDocument();
    doc.Load("invoices.xml");

    XmlNodeList selection = doc.SelectNodes(EXPRESSION);
    double total = 0;

    foreach (XmlNode n in selection)
    {
        total += XmlConvert.ToDouble(n.InnerText);
    }

    Console.WriteLine("sum: {0}", total);
}

The better approach. Note the usage of the sum Xpath expression.

const string SUMEXPRESSION = "sum(/Invoices/Invoice/LineItems/LineItem/Price/text())";

static void UseNavigatorEvaluate()
{
    XPathDocument doc = new XPathDocument("invoices.xml");

    XPathNavigator nav = doc.CreateNavigator();

    Console.WriteLine("sum: {0}", nav.Evaluate(SUMBLOCKED EXPRESSION;

}

Throw Trap

Manoj G — Sun, 24 Oct 2004 12:55:00 GMT

Often, in exception handling, we would need to re-throw an exception caught in the catch block, after doing some operation (logging the exception, for instance). But, we generally make the mistake of providing the exception argument in the throw expression. The problem is that, in this case, we might lose the original call stack. Here's a small snippet to give you the idea:

static void exA()
{
   try
   {
        exB();
   }
   catch(Exception ex)
   {
        //Watch out!
     //throw ex;

     //Better
     throw;
   }
}

static void exB()
{
   throw new Exception("New Exception");
}

static void Main(string[] args)
{
   try
   {
        exA();
   }
   catch(Exception e)
   {
     Console.WriteLine(e.StackTrace);
   }
}

If we were to do a throw ex in the above snippet, then we would have the following stacktrace. Note that we have lost exB() in the stack trace.

exA()
Main(String[] args)

If we were to just re-throw the exception, then we would have got the entire stack trace

exB()
exA()
Main(String[] args)

For more information refer to the C# Language Specification and Lance Hunt's C# Coding Guidelines for .NET.

Process.Start() Quips

Manoj G — Sat, 23 Oct 2004 11:15:00 GMT

It is more than a common requirement to be able to start another process from executing code. For instance, you might want to execute a batch file, run a command line utility of sorts, and so on. This is facilitated in the BCL through System.Diagnostics.Process class, more specifically, the Start method.

Process.Start("Notepad.exe");

You can also specify startup information like FileName, Argument, WindowStyle and so on, through the instance of another class called ProcessStartInfo.

ProcessStartInfo oStartInfo = new ProcessStartInfo();
oStartInfo.FileName = "Notepad.exe";
oStartInfo.Arguments = "MyWork.txt";
Process.Start(oStartInfo);

Simple. But there is a catch here. The instance of ProcessInfo bears a property called UseShellExecute. A value of true for this property would mean that the windows shell is used to start a process, and this is the default value. Therefore, you wouldn’t be able to extract the output or provide an alternative input for the process to be executed. This feature would be required, for instance, if you want to capture the output of a SQL script execution through osql.exe or as another example, the output of a command-line setup. So, to make this work, we need to set UseShellExecute to false and then, as required, set RedirectStandardInput (default is keyboard), RedirectStandardOutput (default is monitor), RedirectStandardError (default is monitor) properties to true. One thing to keep in mind, in this case is that, you should specifiy the full path of the executable or the path must be listed in the PATH environment variable. The code snippet given below captures the execution of a batch file and writes it to a log file:

Process runCmd = new Process();
runCmd.StartInfo.FileName = "RunBatch.bat";
runCmd.StartInfo.UseShellExecute = false;
runCmd.StartInfo.RedirectStandardOutput = true;
runCmd.Start();

FileStream fs = new FileStream("OutPut.log",FileMode.Append);
StreamWriter sw = new StreamWriter(fs);
sw.Write(runCmd.StandardOutput.ReadToEnd());
runCmd.WaitForExit();

sw.Close();
fs.Close();

Another simple tip is that, when UseShellExecute is true, you can start any document if its file type is associated with an executable that has the default action as open. For e.g. The following code launches test.txt in default text editor (notepad on my m/c)

ProcessStartInfo psi= new ProcessStartInfo(@"C:\test.txt");
Process.Start(psi);

You can say also associate verbs like Print etc.

ProcessStartInfo psi= new ProcessStartInfo(@"C:\test.txt");
psi.verb = "Print";
Process.Start(psi);

As another example, the following code launches the URL provided in the default browser.

Process.Start("http://www.microsoft.com");

Tip: StrongNameIdentityPermission

Manoj G — Wed, 20 Oct 2004 20:04:00 GMT

Many a times in your application, you would want to have a security scheme which would ensure that your code is not referenced and misused by other assemblies. For instance, there might be public types representing custom Identities and Principals which you wouldn’t want other applications to use, or some sensitive/proprietary logic, you name it. .NET BCL does provide a handy class StrongNameIdentityPermission which gives you a simple scheme for effecting the same.

You can refer to this walkthrough for more information on how this permission can be used. Also, check this blog entry and the related discussion for more insights.

Indexer Insights

Manoj G — Fri, 15 Oct 2004 11:29:00 GMT

We all know that types, including interfaces can have a default property. Default properties are used as a short-hand notation for accessing items in an array/collection of objects contained within the object. For e.g. Item is the default property of an ArrayList (for that matter, IList.Item) which gets the object stored in the specified index. For eg :

Dim arrItems As New ArrayList
Console.WriteLine(CType(arrItems(0), String))
'Equivalent to this
'Console.WriteLine(CType(arrItems.Item(0), String))

In C#, default properties are called Indexers. There is a subtle difference in the way indexers are declared in VB.NET and C#. Here's an example (MSDN):

' Visual Basic
' A class that contains many Widgets
Public Class Widgets
    'Default property implementation
    Default Public Property Widget(ByVal I As Integer) As Widget
        Get

        ' Implementation code to return a widget goes here.

        End Get

        Set(ByVal Value As Widget)

        ' Implementation code to set a widget goes here.

        End Set
    End Property
End Class

// C#
// Class that contains many Widgets.
public class Widgets
{
    // Indexer implementation.
    public Widget this[int index]
    {
        get
        {
            // Insert code to return a Widget.
        }

        set
        {
            // Insert code to set a Widget.
        }
    }
}

If you notice, there is no provision to specify the name of the Indexer in C#, as present in VB.NET. In C#, the name defaults to "Item". However, you can specify a name by means of an attribute as shown below:

[System.Runtime.CompilerServices.CSharp.IndexerName("Widget")]
public int this [int index] { }

Here are some other aspects of an Indexer we need to know:

1. You can have only one Default property/Indexer per class. The Indexer, however, can be overloaded.

2. Default properties should accept parameters. We cannot have VB6 like (parameterless) properties. Refer to this link for Property changes in VB.NET as compared to VB.

Finally, a tip to end this note on indexers; a frequently asked question in the newsgroups. If we need to find out programmatically, if a class has an indexer, we can query a custom attribute called DefaultMemberAttribute attribute using Reflection as shown below:

static bool CheckIfIndexerPresent(Object obj)
{
    object[] oAttributes = obj.GetType().GetCustomAttributes(true);
    for(short j = 0; j < oAttributes.Length; j++)
    {
        if (oAttributes[j] is DefaultMemberAttribute)
        {
            return true;
        }
    }
    return false;
}

Tip: Checking whether an Assembly is compiled in Debug or Release Configuration

Manoj G — Tue, 12 Oct 2004 14:09:00 GMT

Often, it may be necessary to inspect whether a particular assembly was compiled with a Debug configuration (or Release configuration). For instance, you might want to run a tool of sorts on a build folder to ensure that all assemblies are compiled in the Release configuration. The reason being that - in Debug mode, certain JIT optimizations are turned off (to aid debugging) and you would want them to be turned on for the production environment.

We can inspect this by checking for an attribute DebuggableAttribute (System.Diagnostics namespace) in the assembly metadata. The compiler would automatically qualify the assembly/module with this attribute when compiled in the debug configuration. All we need to do is use Reflection to extract this information out. Given below is a C# code snippet for the same [Courtesy: Nick Weinholt (MVP), News Groups]:

static bool IsDebugMode(Assembly objAssembly)
{
    object[] atts = objAssembly.GetCustomAttributes(typeof(DebuggableAttribute), true);
    if (atts.Length == 0)
    {
        Console.WriteLine("This is a Release Configuration");
        return false;
    }

    DebuggableAttribute da = atts[0] as DebuggableAttribute;
    if (da != null)
    {
        bool standardDebugBuild = da.IsJITOptimizerDisabled && da.IsJITTrackingEnabled;
        Console.WriteLine("Standard DebugBuild = {0}", standardDebugBuild);
        return true;
    }
    return false;
}

String.Format: A Simple Tip

Manoj G — Wed, 29 Sep 2004 12:43:00 GMT

More often than not, we end up concatenating strings in our application code, and a bit aggressively. Sometimes, these concatenations can get a ugly, resulting into a mire of single quotes, double quotes and escape sequences. A simple case of not-so lucid concatenation is shown below:

string consoleMessage = "Time taken by operation: " + operation + " under category: " + category + " :" + time.ToString() + " ms";

A much better approach would be to use the string.Format method which makes concatenations much more readable and less error prone. The same example can be replaced with:

string consoleMessage = string.Format("Time taken by operation: {0} under category {1}: {2} ms", operation, category, time);

Simple. Create placeholders by inserting {n} into the string, where n describes the position of the replacement parameter.The StringBuilder too comes with the AppendFormat method which serves the same purpose. Now, here is a small catch. What happens if the format string itself has "{" or "}"?

strProblemFormat = "{Now, this is a problem}, {0}";

In this case, you would end up getting a FormatException. The solution however, is simple. Escape "{" with "{{" and "}" with "}}" in your format string.

string strProblemFormat = "{{Now, this is a problem}}, {0}";
string strDisplay = string.Format(strProblemFormat, "Not anymore!");

[Updated] I got a lot of flak for chosing a SQL example for string concatenation! As many of the comments rightly indicate, concatenations on SQL statements could potentially invite SQL injection attacks. Parameterized SQL in such cases is a better choice. Thanks for the feedback!

Getting the best of the two (otherwise mutually exclusive) worlds together!

Manoj G — Thu, 26 Aug 2004 09:01:00 GMT

We generally don’t talk about .NET and J2EE together unless, it's a heated debate as to which is better and why. Recently, I came across two very interesting tools which, sort of glues the otherwise mutually exclusive worlds together. The first of which is MainSoft Visual MainWin, a tool which helps C# and VB.NET developers to develop applications for J2EE platform! Do have a look at the published whitepapers here to see how the magic really happens.

Just to summarize, MainWin integrates with VS.NET seamlessly and has a compiler which converts MSIL code to Java Bytecode, which eventually executes on a JVM. Two impressive aspects of the tool are :

Accessing JDK classes and EJB components from C# and VB.NET.
Debugging : MainWin allows you to debug C#/VB.NET applications running on a JVM, using the full gamut of debugging features that VS.NET provides. This is really interesting, considering the amount of plumbing that might be required at runtime.

Isn't this testimonial to the fact that VS.NET is a “high productivity” developer tool? In fact, the first tenet mentioned in the whitepaper of MainWin is "Preserve the Visual Studio Developer Experience".

The next really interesting tool was IKVM.NET, which basically is a JVM for .NET and Mono runtimes. So, this is sort of a converse technology to MainWin. Using IKVM.NET, one can run Java applications on the .NET runtime by converting Java Bytecode to CIL. IKVM comes with an implementation of GNU Classpath in .NET. So, normal C# apps can leverage the entire Java class library. Also, IKVM.NET comes with a tool which converts .NET assemblies to Jar files which can be consumed by Java applications. You can also check out the IKVM.NET weblog here.

I have not really worked with IKVM.NET nor MainWin, or for that matter Java/J2EE. So, I am not in a position to really justify the practical value of these tools (I guess, there should be). But I thought it is worth mentioning about these because, if not for anything else, they can really be appreciated from the academic perspective !

CallContext

Manoj G — Fri, 30 Jul 2004 13:26:00 GMT

Many a times, it would be necessary to share some common information/data between methods that form a call chain. For example, consider a call chain like the one shown below:

A(); --> B() --> C() --> D();

And lets say B,C and D need to access some information created in A. Lets look at some common ways of doing it

1. Create placeholder parameters in all methods.

This is the least elegant solution in most situations, especially in cases where that data is optional. Creating overloads might clutter up the class definition.

2. Using static members/properties

class DataStore
{
    private static Hashtable _slots = Hashtable.Synchronized(new Hashtable());

    public static Hashtable Slots
    {
        get { return _slots; }
    }
}

Static instances live until the AppDomain unloads and can be used to house data, and they would be used through the Singleton pattern. This may be a better solution than creating as many parameters in each method in the call stack. But, you would need to be careful with its design and usage as you may need to synchronize access to a static member in a multi-threaded environment. It would be nice to have a framework expose a common data store which could be accessed across methods. CallContext is just that.

The CallContext class provides data slots that are unique to each thread of execution. You can use the SetData and GetData methods to create and retrieve values from named place holders. The usage seems very similar to that of named/unnamed data slots of the Thread class. So, you may ask - When do I use which method? The answer really lies in the namespace CallContext lies in : System.Runtime.Remoting.Messaging and this is where the similarity ends. Using CallContext, data can be passed along with method calls that are remoted (which execute in different a AppDomain). However, to make this work, the classes of those objects have to implement ILogicalThreadAffinative interface. This interface is just a marker and does not contain any methods to be implemented. And of course, the objects should be serializable.

One good use of CallContext could be a case where a caller's Identity information could be stored in the call context. The remote method call could access this information to implement some sort of a Role-based Security.

You can also have a look at this well-written entry on CallContext. For more information and samples, refer to MSDN.

XML API - When to use What?

Manoj G — Thu, 01 Jul 2004 17:23:00 GMT

I came across this old, but excellent MSDN TV presentation, by Don Box, on ways of using XML API or passing XML data around within an Appdomain. The presentation starts off by discussing pros and cons of passing XML in the form of XmlNode and XmlReader types. In a gist, XmlNode is very easy to use, but taxing on memory as it requires you to create an in-memory representation (DOM) of the Xml data. Also the XmlNode is not read only and you can change the cached Xml structure by calling methods like SetAttribute, AppendChild etc. XmlReader is a better approach in terms of performance, is read only, but is very hard to use. So, the approach that can give the best of the two worlds is XpathNavigator present in System.Xpath namespace. The advantage of the XPathNavigator is that it is read only, extensible, and does not impose an representation constraint like DOM. Classes can override XPathNavigator class and provide their own representations. Excellent examples are - creating a navigator to traverse a File system directory structure or Registry structure using the XpathNavigator semantics. You can download the implementation here. Also, go through this fantastic article by Aaron Skonnard relating to the same discussion.