July 2004 - Posts
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.
1.Articles at ObjectMentor
Fabulous articles and white papers in a number of topics, dealing with Design, Patterns, Development Process and much, much more. A must visit.
2. Downloads at IDesign.NET
Fantastic set of code samples on .NET (Includes C# 2.0 samples). Code samples range from simple to fairly advanced implementations - Implementing ISynchronizeInvoke for instance.
COmega is a research language (from MSR, where else) which gives really powerful extensions to C#.
To summarize, there are two extensions : X# (Xen) and Polyphonic C#. Check out COmega Home for more on what these really are.
You can download the COmega compiler preview from the MSR downloads page. This includes VS.NET templates, command line tools, documentation and lots of samples.
I was blown away by the raw power Comega provides as a programming language. So much so, that I am really interested in joining a COmega SIG, if there is one, or probably start one, perhaps !!!
I have not yet really delved into all aspects of the language (especially Polyphonic C#), but will do it and will definitely come back with more posts on the same.
My start with VS 2005 has rather been a bit sluggish. I didn’t really work much with the Community Tech Preview, but when I got the Beta 1, I decided to get my hands real dirty with it. At about the same time, I cam across a few excellent resources at MSDN (especially, A Sneak Preview of Visual Basic 2005). All the new enhancements are great and do take developer productivity to a new high. But its worth mentioning about my top picks (of today):
ClickOnce
I must say my most favorite of the all features in .NET 2.0 is ClickOnce Installation. The concept of Smart Client is indeed revolutionary, because it brings together the best of the two worlds : Easy deployment model of thin clients and Rich UI of the thick client applications. The earlier version of .NET gave a good headstart in this direction, but was littered by limitations that definitely needed to be addressed. ClickOnce does just that. These are the salient features:
- Easily configure and publish applications from the VS IDE. You can even use a friendly wizard for this purpose.
- Applications can now be configured for offline access. Applications are actually installed on the machine with entries made to Add/Remove Programs snap-in
- Applications can now Auto-Update themselves when newer updates are available.
For more info on ClickOnce, refer to this MSDN Mag Article and this MSDN TV Presentation
Edit And Continue [EnC]
An uproar is always in the making if a great feature exists in a previous version is not available in the next. Well, that was the case with Edit and Continue, a feature loved and used by VB devs in the past. So much so, that a lot VB6 friends I know of, actually develop only in the VB6 debugger! In VB6, as you all know, applications are compiled into P-Code (Pseudo Code) and not native code in debug mode. So, under the VB debugger, the code would be interpreted (highly simplified). It may be naive thinking, but I wonder how the CLR team pulled this one off. I am sure the seemingly simple EnC would be a really hard thing to be implemented.
EnC however, does not make its way into C#. Andy Pennel's[MS] blog entry and JayBaz's [MS] entry give more insight into why this was dropped from C#. Nice posts, don’t miss the comments as well !
ASP.NET also doesn’t have EnC as such but supports “Save and Refresh” style of debugging. Have look at Brian Goldfarb's entry on why this was elided in ASP.NET .
Code Snippets (VB 2005)
This is a real cool feature provided by VB IDE. Through this feature, you can insert code snippets of very commonly used development tasks like creating a file etc into the code by using the context menu. C# does not however, have such an extensive set of snippets and I couldn’t find ways to add my own as I could do with the VB IDE.
One notable absence in VB 2005 is Refactoring. Paul Vick, in one of his posts explains. It's pretty funny, but many say that Refactoring is somewhat of a "grunge thing" that an average VB developer would not be too bothered about and hence better left out. I don’t agree with that. I feel refactoring, just like designing, is an art, and it would be great to have the support in the IDE. If you have worked with ReSharper, you would know why. I may not be too experienced to completely know VB's philosophy, but I can say that “Keep things simple” and “Make stuff easier” have been the prime doctrines of VB. Now, the thing to ponder about is - doesnt refactoring fit into one of these isms of VB ?
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.