DOT NET TRICKS

I am reviewing Microsoft's 70-515 C# exam PrepKit from UCertify

2012-01-04T01:05:00.003+05:30

I have got a offer from uCertify to review their PrepKit and I have accepted that challenge and now I am reviewing 70-515 Exam .NET 4.0 PrepKit from uCertify. Initially it looks like a simple tool that has a number of practice sets listed on the initial screen to try out few tests. The home screen also contains few links that points to Study Materials related to the exam that you are registered for. Lets take a look how the initial screen looks like :

The menu contains different links to Tests, Quiz, Notes, Articles, Reports etc for easy navigation.

As soon as I am done with the full review I will post it for you all.

If you are looking for a Certification, you can buy it from them :
http://www.ucertify.com/

Thanks and stay tune.

Awarded Microsoft MVP in a row

2012-01-02T02:24:00.002+05:30

Its new years eve. I was struck in traffic to join a Birthday party of one of my friend. Its all of a sudden I realized that it is my MVP renewal date too. I forgot it totally.

I opened my Mobile, browsed to my account and saw, I have got a mail from MVP Award Team.

"Dear Abhishek Sur,

Congratulations! We are pleased to present you with the 2012 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Client App Dev technical communities during the past year.

The Microsoft MVP Award provides us the unique opportunity to celebrate and honor your significant contributions and say "Thank you for your technical leadership."

Nestor Portillo
Director
Community & Online Support"

I am really passionate about this award and I am really happy to receive this award for yet another time in Client App Dev category. This came to me as a New Years Gift. Thank you so much Microsoft for considering my activities and I want to personally thank Mr. Abhishek Kant, as my MVP Lead, Abhijit Jana, Kunal Chowdhury, Amit Bansal, Dhananjay Kumar, Pinal Dave, Anoop Madhusudanan and last but not the least my own Community KolkataGeeks all of whom inspired me so much on my community activities. I would also like to thank the whole Microsoft Team for providing us such an opportunity to be in touch with this elite group.

And finally thank you to all my blog readers. I feel truly honored to receive such an award.

Happy New Year to all of you. Its time to party..... .

:)

Daily DotNet Tips 1 year and onwards

2011-12-27T08:53:00.000+05:30

Friends,

We are excited to celebrate 1st Anniversary of our site DailyDotnetTips today. It aims to share useful programming tips for .net developers.This site completely design for sharing Tips and Tricks, useful Code Snippet which anyone use in daily development work and targeted anything related with .NET.

Here is some of the statistics :

Founded : 27th December 2010
No of Posts : 250
No facebook likes : 502
No of participants : 7
No of Twitter followers : 348

We are still a long way to go. Follow us and be a part of it.

www.dailydotnettips.com

DEVCON – Kolkata, A New Beginning on 12th November, 2011

2011-11-10T21:31:00.001+05:30

November 12th , we are getting together for a big event Developer Conference 2011 Organized by Microsoft User Group Kolkata (KolkataGeeks) . Developer Conference is the premier technical event for technology professionals at Kolkata interested in learning, connecting and exploring latest Microsoft technologies. This is also going to be community Launch event for Office 365. So be there and enjoy the flavor of cutting edge Microsoft technologies.

This is a full day event and you can attend this event in person at Bharatiya Bhasha Parisad 36A, Shakespeare Sarani, 4th Floor Kolkata – 700017. Overall there are 7 different sessions which primarily focused on latest Microsoft Technologies. . Check the Dev Con Web Site for more information.

I’ll be presenting on “Windows 8 Metro Style Application“. In this session I will talk about latest Windows release and how you can get best out of it through your Metro Style applications. There will be lots of demo in this session.

Check out session details and agenda from here http://kolkatageeks.com/DevCon2011.aspx . You can register for this event over here http://kolkatageeks.com/DevCon2011/Register.aspx

See you there !

Layout adjustments Snapping and OrientationChanges in Metro Applications

2011-10-31T06:06:00.001+05:30

If you have read my first article on Windows 8 metro styled application, you might already know about the working principle of it. I have talked about the capabilities for an application and settings which end user can configure for an application. In this post I will take a look at the basic layout structure that one needs to follow while creating an application in WinRT Metro styles so that it is best suited to perform well.

Layout is the most important part of any application. The best design for an application gets more credit and love from the users than applications that are designed bad. Metro style applications runs in full screen. Your application does not include a Title Bar, status bar or anything. Microsoft gave us some of the basic layout guidelines that one needs to follow. Lets talk about them here to make you understand how you should layout your application in Metro Applications to utilize maximum flexibility of it.

Lets start defining a layout and explain each section.

<UserControl x:Class="LayoutSample.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Loaded="UserControl_Loaded"
    d:DesignHeight="768" d:DesignWidth="1366">
    
    <Grid x:Name="LayoutRoot" Background="#FF0C0C0C">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto"/>
            <ColumnDefinition Width="320"/> 
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <Rectangle x:Name="rctSpacerLeft" Width="120" />
        <Border x:Name="brdHeader" Height="140" Grid.ColumnSpan="2" Grid.Column="1">
            <TextBlock HorizontalAlignment="Left" VerticalAlignment="Center" Text="My Basic Layout"
                       FontSize="40"/>
        </Border>

        <ListBox x:Name="lstBasicItems" Grid.Row="1"
                 Grid.Column="1">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Vertical" >
                        <TextBlock Text="{Binding Name}" HorizontalAlignment="Center"/>
                        <TextBlock Text="{Binding Description}" HorizontalAlignment="Left"/>
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>
        <Grid x:Name="grdLayoutRight" Grid.Row="1" Grid.Column="2" DataContext="{Binding ElementName=lstBasicItems, Path=SelectedItem}">
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto" />
                <RowDefinition Height="*"/>
            </Grid.RowDefinitions>
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="Auto" />
                <ColumnDefinition Width="*" />
            </Grid.ColumnDefinitions>
            <TextBlock Text="Name" FontSize="14" />
            <TextBox Text="{Binding Name}" Grid.Column="1" />
            <TextBlock Text="Description" FontSize="14" Grid.Row="1" />
            <TextBox Text="{Binding Description}" Grid.Column="1" Grid.Row="1" />
        </Grid>
    </Grid>
    
</UserControl>

This is a basic layout of an application which shows a list of data in the left hand side in a ListBox and the Right hand side shows few textboxes to edit the data. Following the convension, each application should have a left margin of 120 px. In this layout the First Column of the LayoutRoot grid is specified Auto. Auto indicates that the portion of the screen will be sized to content. In this section I specified a Rectangle with width 120px.
Again the Application needs to have a Heading. I have specified the heading in the First Row of the Grid. The ListBox is taken as 320px, this is because when the application is snapped, it takes 320px of size based on the design resolution. The Grid is *(star) Sized, hence it will adjust the size based on the available space.

Now if you run this code, you will see something like this :

Here the ListBox takes 320 px of size and the Grid takes the rest of the available space. Now if you snap the application with another application, it will not adjust the size automatically. Lets write code so that it does.

public MainPage()
{
    InitializeComponent();
    var currentView = ApplicationLayout.GetForCurrentView();
    currentView.LayoutChanged += new TypedEventHandler<ApplicationLayout, ApplicationLayoutChangedEventArgs>(currentView_LayoutChanged);
}

void currentView_LayoutChanged(ApplicationLayout sender, ApplicationLayoutChangedEventArgs args)
{
    switch (args.Layout)
    {
        case ApplicationLayoutState.Filled:
        case ApplicationLayoutState.FullScreen:
            this.rctSpacerLeft.Visibility = Windows.UI.Xaml.Visibility.Visible;
            this.brdHeader.Visibility = Windows.UI.Xaml.Visibility.Visible;
            break;
        case ApplicationLayoutState.Snapped:
                this.rctSpacerLeft.Visibility = Windows.UI.Xaml.Visibility.Collapsed;
                this.brdHeader.Visibility = Windows.UI.Xaml.Visibility.Collapsed;
            break;
    }
}

So here you can see I have made the rctSpacerLeft and brdHeader visible only when the state of the application is Filled (that means when some other application is snapped with the application) or when the application is FullScreen (that means when the whole application is showed up). But these elements need to be Collapsed whenever the application is in Snapped mode(when the current application is snapped).

You should already know, basically applications has 3 states. One when the size of the application is 320px long (called snapped ), when the application is filled most of the space just leaving 320px of the entire screen for some other application or when the application is full screen.

In the above image, I have just snapped the Tweet@rama that comes preinstalled with Windows 8. You can see the Grid is sized smaller than the previous one sharing the the 320 px of the entire screen to the other application. Here the Margin is kept intact.

But when the current application is snapped state, we need to show the entire thing in 320px. So the application needs to adjust itself to be meaningful to the User.

When I snap the current application with Tweet@rama, you can see, it removes the header, the spacer margin and the Grid that is auto sized.

Responding to Rotation

Responding to Ration of the device is another important consideration that you should always keep in mind while designing a Metro styled application. To know the Native Orientation of the device when the application gets started, you can use the DisplayProperties.CurrentOrientation property.

Lets modify the code to show the Orientation of current device in header. By default the orientation is Landscape.

The above image shows up the current Orientation of the device. Lets edit the xaml a bit to introduce it.

<Border x:Name="brdHeader" Height="140" Grid.ColumnSpan="2" Grid.Column="1">
      <TextBlock HorizontalAlignment="Left" VerticalAlignment="Center"
                 FontSize="40">
          <Run Text="My Basic Layout" />
          <Run x:Name="runOrientation" />
      </TextBlock>
</Border>

I have added a couple of Run statement to allow changing the Orientation text in one particular Run block inside the TextBlock. Now lets handle the OrientationChanged Event of DisplayProperties to get the current Orientation. To do this lets add this code :

public MainPage()
{
    InitializeComponent();
    var currentView = ApplicationLayout.GetForCurrentView();

    currentView.LayoutChanged += new TypedEventHandler<ApplicationLayout, ApplicationLayoutChangedEventArgs>(currentView_LayoutChanged);

    DisplayProperties.OrientationChanged += new DisplayPropertiesEventHandler(DisplayProperties_OrientationChanged);
}

void DisplayProperties_OrientationChanged(object sender)
{
    this.WriteOrientation();
}
void WriteOrientation()
{
    this.runOrientation.Text = string.Format(" ({0})", DisplayProperties.CurrentOrientation);
}

Here we initialize the new event handler for OrientationChanged in constructor of MainPage, which will call the event whenever the orientation of the device is changed. DisplayProperties also lists many other display related properties like ColorProfileChanged, LogicalDpiChanged etc but they are rarely needed. You can read them from here.

Download Sample Project

Conclusion

To write a general purpose application, it is very important that your application maintains proper layout when the device changes its size or shape. The objective of the post is to get you through understanding how you could form a good layout for your application. I hope you have already got the basics of how to layout the application in Metro Environments.

I hope this post helped you.

Thank you for reading.

Understanding basic WinRT Metro Applications and Application Capabilities

2011-10-30T06:47:00.000+05:30

Just about a month ago, WinRT was introduced with all new style of application development that can work better with Multi Touch Enabled devices. We call it as Metro Applications. In this post, I will discuss how to develop your first metro applications and how to work with its layout changes.

How to Start

Before we start talking directly about Metro Style application, let us see how to install it first. I refer to use OracleVM which you can find for free from this link, and install. This will install a Virtual Machine in which you can install the Developer Preview of Windows 8.

After your Virtual Machine is ready download Windows 8 Developer Preview from this link. Remember you need to install Windows Developer Preview with Developer Tools 64 Bit which is 4.8GB in size if you are willing to develop Metro Style Application. If you have something else, you do not have option than install it again. ( I have lost several hours trying on other windows previews). If you are having problems while installing Windows 8 in your Virtual Box, please follow the steps mentioned here.

After you install Windows 8 in your virtual machine please make sure you change the resolution to something above 1152. It is important because anything below this will turn of certain things. You cannot open Metro Apps or you cannot apply Partial fill settings of your application when the resolution is below this range.

Another Important consideration

You must remember, Metro application does not support closing the application, at least now. Hence if you start a new application the other application will keep on running in background. You can switch back to that by hovering the left hand side of the screen and dragging back to the working area. Shortcut to do this is Windows + Tab. The only way to close is either using an explicit close button from the application itself, or using Alt + F4 key from the keyboard.

The Desktop Tile
Metro application is designed in such a way that the tiles are capable of update itself and it is easier to work with them using your hand. But like me most of the people might want the desktop on which we are all familiar of in windows. Yes Metro has a Tile called Desktop Tile that can present you with the very old Desktop with applications that are meant to run in desktop. You can move back and forth to this Desktop tile when you want.

So the one that is marked represents the Desktop Tile. You can also see Visual Studio and other developer tools appear in the same picture as Tile. The Visual Studio Express will help you build your first metro applications.

Application Store

Application store is another important point to note for Metro style application. After you package a metro style application you need to publish it and upload it to Application Store with all the important information of it clearly. The user that needs the application should connect to the application store and download the same. This way the user is always aware of what he is downloading and what the application does.

Now as you know much about Metro applications, lets start writing one metro application.

What are Capabilities?

Just like Silverlight or Windows Phone, Metro applications run in a very constrained mode. That means when you install the metro application you should provide the entire rules which the application should follow. That is to say if you do not specify that the application needs internet access to run the application, you would not get it from the application either. Hence Capabilities are defined set of rules that govern the application to access certain functionalities that application needs.

When you create a blank application in Visual Studio, you will see a appmanifest file that exists for each application. It is nothing but an XML file where you need to specify capabilities, Application related metadata etc. You can easily open that file in XML editor and add Capabilities like below :

<Capabilities>    
    <Capability Name="internetClient" />
</Capabilities>

But you dont need to. If you double click on the File Package.appmanifest, you can edit to add Capabilities from a list of Capabilities that are commonly used. For instance Internet is checked by default. Lets add Location in this list. Location will allow you to get Latitude/Longitude information of the device.

When you run an application, it deploys the application automatically to metro application without the need of Application store. Hence you dont need to wait until the application store approves your application to run. This is called as side loading which the end user cannot do as it is explicitly restricted to Visual Studio. Now if you run your application, you will see a blank black screen appear after the initial flash screen.

Lets run the project and swipe the application by hand to see some settings. You can also hover over the left hand bottom of your application to open the same settings or use Windows + I.

Here you can see some standard settings that appear on the bottom of the sidebar. The Application information is also specified in the top of the side bar. And a special link which indicates the application capabilities. Lets click on it to see which capabilities are there for me.

I have asked for Location, Proximity and Internet access, and hence it shows up in this list. You can see there is one additional settings called Location listed as Off above the list.

Certain features needs explicit access by the user when the application request it. Location is taken as sensitive capability, and hence it will again ask the user to enable it when you first call it and the user has the option to block this too.

Now lets write some code to access the Location and see what happens to the application.

We add some basic XAML to the application which adds one TextBlock and one Button. So when the Button is clicked the Textblock updates the current location of the device.

Lets see how xaml looks like:

<UserControl x:Class="Metro1SimpleApp.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Loaded="UserControl_Loaded"
    d:DesignHeight="768" d:DesignWidth="1366">

    <Grid x:Name="LayoutRoot" Background="#FF0C0C0C">
        <Grid.RowDefinitions >
            <RowDefinition Height="120" />
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="120"/>
            <ColumnDefinition Width="*"/>
        </Grid.ColumnDefinitions>
        <StackPanel Orientation="Vertical"  Grid.Row="1" Grid.Column="1">
            <TextBlock x:Name="txtLocation" Text="Your Current Location is : "/>
            <Button Click="Button_Click" Content="Update Location" />
         </StackPanel>

    </Grid>

</UserControl>

Here the code adds one TextBlock and a Button that acts just like regular controls. If you try to know from inside these controls are wrappers to WinRT controls. Now the Button has a Click Handler defined and the UserControl also defines the Loaded event handler.

Now lets write code for those handlers :

private async void Button_Click(object sender, RoutedEventArgs e)
{
    await UpdateGeoLocationAsync();
}

private async void UserControl_Loaded(object sender, RoutedEventArgs e)
{
    await UpdateGeoLocationAsync();
}

private async Task UpdateGeoLocationAsync()
{
    Geolocator location = new Geolocator();
    Geoposition position = await location.GetGeopositionAsync();

    this.txtLocation.Text = string.Format("Your current position is :({0}, {1} ", position.Coordinate.Latitude, position.Coordinate.Longitude);
}

Geolocator is an WinRT API that calls for a GeoPosition either by using satellite position (if appropriate sensor is found in the device) or using internet address of the IP. Now this is slow API and hence WinRT allows you to only invoke asynchoronous call to this api. We use the new async support here to call the API.

If you dont know about async, please read my article.

We add the contextual await to call from both the UserControl.Loaded and Button.Click event handlers.

When I run the application, it will first ask to unblock the Location API. I have already told you, the location API is taken as sensitive and hence you as an user for the application have the settings to block and unblock. You will see something like below :

Thus it asks to turn on location service. If you allow then only the application can get Location data. Lets allow it, you will see the location is updated.

If you are moving, you can click on the Button on the application to update your location when needed.

Now after you unblock the location API for the first time, if you go to settings, you will see the Location capability is now enabled for you. You can turn on or off whenever you want.

To run on or off, you can drag the button to the right or left.

You can download the sample from here.

Even though for a developer coming from normal Windows application it may seem to you as weird to have such kind of security enabled for your application, but world is moving towards it and this will benefit the end user to have clear knowledge about what the application is capable of. Hence it adds up security to the whole system.

Conclusion

This is still very early stage of WinRT to talk about. There may be some amount of changes in final release of it. But yet it is good to learn about it. I hope you like my post. I will update with more posts on WinRT metro application in near future.

Thanks for reading.

Regular Expressions with Timeout in .NET 4.5

2011-10-21T06:31:00.000+05:30

.NET 4.5 Developer preview is out with Visual Studio 2011. I was already thinking to try out what's new in .NET 4.5 myself and share what exactly been changed.

Lets start by the new Regex Api introduced with the framework. The improvement that has been made is minor yet handy at certain cases. The Regex class of .NET 4.5 supports Timeout. Lets take a look how to work with it.

Lets try to write a simplest RegEx validator to look into it.

try
{
    Regex regexpr = new Regex("[A-Z ]{10}", RegexOptions.Singleline, TimeSpan.FromMilliseconds(1));
    Match mch = regexpr.Match("ABHISHEK SUR");
    if (mch.Success)
        Console.WriteLine("Match found");
    else
        Console.WriteLine("Not matched");

}
catch (RegexMatchTimeoutException ex)
{
    Console.WriteLine("Regex Timeout for {1} after {2} elapsed. Tried pattern {0}", ex.Pattern, ex.Message, ex.MatchTimeout);
}
catch (ArgumentOutOfRangeException ex)
{
    Console.WriteLine(ex.ToString());
}
finally
{
    Console.ReadKey(true);
}

Here in the code you can see I simply check a string with a Regular expression. It eventually finds success as Pattern matches the string. Now this code is little different than what we have been doing for last few years. The constructor overload of Regex now supports a Timespan seed, which indicates the timeout value after which the Regular expression validator would automatically generate a RegexMatchTimeoutException. The Match defined within the Regex class can generate timeout after a certain time exceeds.

You can specify Regex.InfiniteMatchTimeout to specify that the timeout does not occur. The value of InfiniteMatchTimeout is -1ms internally and you can also use Timespan.Frommilliseconds(-1) as value for timespan which will indicate that the Regular expression will never timeout which being the default behavior of our normal Regex class. Regex also supports AppDomain to get default value of the Timeout. You can set timeout value for "REGEX_DEFAULT_MATCH_TIMEOUT" in AppDomain to set it all the way through the Regular expressions being used in the same AppDomain. Lets take a look how it works.

try
{
    AppDomain.CurrentDomain.SetData("REGEX_DEFAULT_MATCH_TIMEOUT", TimeSpan.FromMilliseconds(2));

    Regex regexpr = new Regex("[A-Z ]{10}", RegexOptions.Singleline);
    Match mch = regexpr.Match("ABHISHEK SUR");
    if (mch.Success)
        Console.WriteLine("Match found");
    else
        Console.WriteLine("Not matched");

}
catch (RegexMatchTimeoutException ex)
{
    Console.WriteLine("Regex Timeout for {1} after {2} elapsed. Tried pattern {0}", ex.Pattern, ex.Message, ex.MatchTimeout);
}
catch (ArgumentOutOfRangeException ex)
{
    Console.WriteLine(ex.ToString());
}
finally
{
    Console.ReadKey(true);
}

Now this works exactly the same as the previous one. Here the Regex constructor automatically checks the AppDomain value and applies it as default. If it is not present, it will take -1 as default which is Infinite TImeout and also if explicitely timeout is specified after the default value from AppDomain, the Regex class is smart enough to use the explicitly set value only to itself for which it is specified. The Regex Constructor generates a TypeInitializationException if appdomain value of Timespan is invalid. Lets check the internal structure.

This is the actual code that runs in background and generates the timeouts. Infact while scanning the string with the pattern, there is a call to CheckTimeout which checks whether the time specified is elapsed for the object. The CheckTimeout throws the exception from itself.

The Constructor sets DefaultMatchTimeout when the object is created taking it from AppDomain data elements.

If you read MSDN thoroughly, it suggests to use Timeouts when specifying the Regular expressions. If the pattern is supplied from external or you are not sure about the pattern that needs to be applied to the string, it is always recommended to use Timeouts. Basically you should also specify a rational limit of AppDomain regex default to ensure no regular expression can ever hang your application.

This is a small tip on the new Regex enhancements introduced with .NET 4.5 recently. I hope you like it. More to come shortly, stay tune.

Thank you for reading

Generic Types and Static Members

2011-10-07T05:34:00.001+05:30

One of my friend recently asked me a question that I think I should share with you. Say you have a Static Implementation of a Type T which you pass as Open Type in your Generic Class. Now the problem is how to get reference to the Static Members or invoke a method that is Static to the Type from the Open Type T. In this post, I will demonstrate few implementations that help you getting the Static implementation.

First of all, According to C# documentation, any type allocates its static members once per Type rather than once per Open Type. Now lets define this using the code below :

public class MyType<T> where T : class
{
    public static int Counter;
    static MyType()
    {
        Counter = 0;
    }
    public MyType()
    {
        Counter++;
    }
}

Here this is actually a Generic Type that keeps track of the count of objects that per type creates. The Type instance here MyType<T> is called Open Type and can take form of any Type. Now lets create object of MyType.

MyType<string> ss = new MyType<string>();
ss = new MyType<string>();
ss = new MyType<string>();
MyType<object> oo = new MyType<object>();
oo = new MyType<object>();
oo = new MyType<object>();

Console.WriteLine(MyType<string>.Counter);

Console.ReadKey(true);

Now we create 3 instance of string and 3 of Object. Thus the Console.WriteLine should show 6, right? .... Wrong.. Actually we here create two types using Generic Type MyType, one is MyType<string> and another is MyType<object>. So here MyType generates its own closed type and each of the type creates its Type interface when first instance of the object is called for, or rather when the Static constructor is called.

Thus if I call MyType<X>.Counter it will show 0 and will create a new Type and call the Static constructor immediately.

Now this is very easy here to call static members of a Generic type, but what if we want to call Static member of the Type we pass into as Generic Argument. Lets see...

public class MyType
{
    public static void Try2CalMe()
    {
        Console.WriteLine("Wow. You finally called me!");
    }

    public void CallMe()
    {
        Console.WriteLine("Called CallMe");
    }
}

Lets say I have a class defined with one static method and one instance method. As I have already told you that Generic Static members create its memory when it creates it first object, the same is true for non generic types. Hence when an instance of MyType is passed within a Generic Type as Type argument, you would already have the memory allocated for the Type. Now let us consider using this Type for our Generic Class.

public class MyGenericClass<T> 
{
    T MyTObject { get; set; }
    public void InstanceMethod()
    {
        if (this.MyTObject != null)
            this.MyTObject.CallMe();
    }
}

Well the line which calls CallMe leads to a problem, because the Generic Type does not have any idea about what Type it is going to take. Say for instance if I pass int variable as T it will take that also. Well to fix this problem we can put a constraint to Type T with a Where clause. But that doesnt solve our problem either. Even though we can call CallMe we cannot call Try2CallMe. There are few approaches that you can take to solve this problem.

Working with your friend Reflection :

Reflection API can call any method from a Type. You can check whether the static Method is there in the type that is passed during Runtime and if exists you can call it. Lets try to call the method using Reflection :

public class MyGenericClass<T> where T : MyType
{
    public T MyTObject { get; set; }
    public void InstanceMethod()
    {
        if (this.MyTObject != null)
        {
            this.MyTObject.CallMe();

            //Calling static member using Reflection

            Type currentType = typeof(T);
            var method = currentType.GetMethod("Try2CalMe", BindingFlags.Static | BindingFlags.Public);
            if(method != null) // Method exists
                method.Invoke(null, null); //We pass null as object for static member

        }
    }
}

So here we first pass MyType as constraint (even though it makes the type strict to inherited members of MyType) and calling the member using Reflection. Yes, it can call it absolutely.

Putting it in intermediate Abstract base class:

Another option, or probably better approach is to create an intermediate abstract base class for all your types and call it. It is another option for you and probably a better one but remember, all of your members share the same static member here.

public abstract class MyAType
{
    public static void Try2CalMe()
    {
        Console.WriteLine("Wow. You finally called me!");
    }
    public virtual void CallMe()
    {
        Console.WriteLine("Called CallMe");
    }
}
public class MyGenericClass<T> where T : MyAType
{
    public T MyTObject { get; set; }
    public void InstanceMethod()
    {
        if (this.MyTObject != null)
        {
            this.MyTObject.CallMe();

            //Calling static member Directly here
            MyAType.Try2CalMe();
               

        }
    }
}

Here we create an abstract base class for MyType and we pass it as generic constraint. So any class that inherits from this base class can go as a Type for the class MyGenericClass and which in turn can call its static member directly.

There might be some other option available and known to you. I would like you to share that with me.

I hope you like this post.

Thanks.

Internals of .NET Objects and Use of SOS

2011-09-26T14:53:00.000+05:30

Well, now getting deeper into the facts, lets talk about how objects are created in .NET and how type system is laid out in memory for this post in my Internals Series. As this is going to be very deep dive post, I would recommend to read this only if you want to kill your time to know the internal details of .NET runtime and also you have considerable working experience with the CLR types and type system.

Recently I have been talking with somebody regarding the actual difference between the C++ type system and managed C# type system. I fact the CLR Type system is different from the former as any object (not a value type) is in memory contains a baggage of information when laid out in memory. This makes CLR objects considerable different from traditional C++ programs.

Classification of Types

In .NET there are mainly two kind of Types.

Value Types (derived from System.ValueType)
Reference Type (derived directly from System.Object)

Even though ValueTypes are internally inherited from System.Object in its core, but CLR treats them very differently. Indeed from your own perception the Value Types are actually allocated in stacks (occationally) while reference types are allocated in Heaps. This is to reduce the additional contension of GC heaps for Heap allocation, GC cycles, occasional call to OS for additional memory needs etc. The object that is allocated in managed Heap is called Managed Object and the pointer that is allocated in stack to refer to the actual object in heap is called Object Reference (which is sometimes called as Managed Pointer).

Additional to this basic difference a Value Type is treated completely different from CLR point of view. CLR treats any object that is derived from System.ValueType differently in respect of any other object derived from System.Object directly. The memory of a ValueType contains just the value of its fields and the size of the Value Type is just the addition to its content, while for reference types the size is completely different. Let us consider looking at the memory layout of both the types.

In case of Value Types, the Managed Pointer holds reference to the initial location of the actual Memory.Thus in this case, the Managed pointer holds reference to 0x0000 which is the address location of Field 1. Hence CLR needs to do pointer arithmetic to find Fields ... N. Thus we can easily use Sizeof operator on ValueTypes to get the actual size of the object.

The reference Types on the other hand holds some complex informations in its header.Lets define the individual blocks that comprises one object using a diagram.

In the diagram, I have depicted the entire layout of memory for a reference type. The initial Managed Pointer here for reference types holds the address of Reference to RTTI address (Run Time Type Information). The initial 4 bytes of the memory is allocated for Synchronization Block. In CLR every object holds its own lock information by itself using this storage. There is another important consideration that you need to think of, is every CLR object holds its Type information inside it. This ensures that every object can explain its own type from itself without any dependency from outside. Hence the reference types are Self Explanatory types and programs can use these information while casting, polymorphism, dynamic binding, reflection etc. Even though the Method Table structure reside outside the actual object, the RTTI Address holds the initial address of the Method Table runtime object which holds all the informations regarding the Type of the object. We query the information of the Runtime Type using the GetType method from any reference Type. The .NET runtime creates a special object of Type which helps to find out the actual type information.

On the other hand, the ValueTypes are simply a chunk of memory without any clue of what it acutally contains. This is the major difference between the two types.

During instantiation, a valuetype automatically calls its default constructor when it is declared. You cannot define default constructor for a ValueType. But language (like C#) puts additional restriction to ensure that the valuetype is initialized before it is used to save additional constructor calls.

ReferenceType on the other hand must have an object assigned to it using new operator. The new operator first allocates memory of its fields with default values and then calls the constructor.

Caveats of CLR Variables

Value Type variable directly represents memory of a Stack.
Reference Type represents a pointer (or probably we should call it as Reference) that refer to the start location of the object produced in Heap. The reference points to RTTI address location.
CPU registers can hold managed pointers as well as managed objects. Hence in certain cases, you can either store your value type or a reference to a Object in CPU registers depending on your need.
AppDomain wide managed Table contains all the references pointing to the managed object references that are marked by GC. It also holds static ValueTypes and static Reference Types.

Implicit Object Reference (this)

There is nothing new with "this". Any instance member have access to this pointer even though they are Value Type or a Reference. The method generally pass the object from which it is called as "this" as first argument of the call. Hence it is available inside any method. "this" pointer for ValueType points to the first instance field address location while the "this" pointer for the Reference Type points to the address of Method Table information.

How CLR Methods are called ?

There are two types of method being called in CLR. One with invoking call IL instruction which needs the current object to be loaded in stack before any other argument passed as parameters; and other by using CallVirt which is almost similar to call, but produces an additional instruction to validate the object reference. The call statement does not produce NullReferenceException to a call to the method, but passes null as "this" pointer. But eventually if there is any instruction that requires access to its field or any other method call, it will produce NullReferenceException. CallVirt directly produces NullReferenceException prior to the call to the method when the object does not assign anything.

When using Interface based methods, the ValueType generally needs to be boxed to produce Method Table information so that the Virtual Methods could be called by CLR. The Reference type does not bother to invoke callvirt which actually translates it based on the type of the runtime object rather than the original type it is called from (interface reference).

Delegates on the other hand is a special type that holds reference of methods. MSIL has two opcodes to deal with them, ldvirtftn that load virtually a method, and ldftn. The ldftn loads the method address into stack. The type of the method token loaded by this IL instruction can be searched to MethodTable of the type to get the actual address of the method. Delegates generally pass the object on which the member needs to be executed as Target and the method address stored in delegate instance to invoke the method. In case of Static method call the target is apssed as null. The process of retrieving an storing address to a delegate is expensive and is called delegate binding.

Delegates are derived from a special type called System.Delegate in .NET CLR. A delegate can hold multiple methods in a chain. You can add more methods of same signature to a delegate which will be invoked sequentially by calling the last method added to it first and thereby calling the first method that is added as the final method in delegate chain. The return statement of the final method call is actually passed to the caller.

Trying out some basic debugging with Son of Strike(SOS)

Before we start SOS debugging with Visual Studio, you should recollect that there are three important data structure that you need to keep in mind.

MethodTable : Stores all information about a Type. Holds information regarding static data, table of method descriptors, pointers to EEClass, pointers to other Methods from other VTable and pointers to Constructors.
EEClass : This is almost same structure as of Method Table, but holds more static data information.
MethodDesc : Information regarding a particular method such as IL or JIT'ed informations.

Now let us consider a dummy class to start debugging.

public class MyClass
{
    public static int RefCounter;
    private int age;
    public MyClass(string name, int age)
    {
        this.Name = name;
        this.Age = age;
        MyClass.RefCounter++;
    }
    private string name;
    public string Name
    {
        get
        {
            return name;
        }
        set
        {
            name = value;
        }
    }
    public int Age
    {
        get
        {
            return age;
        }
        set
        {
            age = value;
        }
    }
    public void GetNext(int age)
    {
        Console.WriteLine("Getting next at age" + age);
    }
}

Here I have defined one static field, two member fields, a parameterized constructor and one instance method to start testing. We will use SOS to test instance of this code.

So as we know already when an object is created, the memory contains an object reference to the actual object placed in heap. Hence lets create an object of it in Main.

static void Main(string[] args)
{
    MyClass obj = new MyClass("Abhishek", 28);
    obj.GetNext(20);
}

To start debugging you need to enable native debugging. To do this, Right Click on project => Debug => Enable unmanaged code debugging. Now put a breakpoint on the first line and step into the constructor. Lets say I go until one instance field is loaded. Now open Intermediate Window and type .load C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\sos.dll. Please replace the exact location if folder structure differs.

Now once the extension is loaded we can examine the instance of MyClass.

We call !DumpStackObjects to dump the object that is loaded in memory. We see something like below :

These are the managed objects that are loaded into memory. Our concern is to see instance of MyClass. So copy the object reference handle of the corresponding Object of MyClass ( in our case it is 00c2c1d0). Now lets use !DumpObj 00c2c1d0

The instruction actually dumped the entire object with the address to MethodTable, EEClass and size of the object in bytes. You can see the size of the object in heap is 16 bytes. This is because the Objects in CLR holds more than the fields and members (like sync headers, method pointers etc.) It also lists the fields currently in memory. You can see Value for name has an address as we execute this after the instruction line name in constructor but before age. Now if I pass through all the lines of constructor it will show the memory address of all the members. You can use !DumpObject to play around the addresses of Name (00c2c1b0) or age or any instance member from here onwards.

Now lets try few more commands to get interesting behaviors. There are few commands that you can try. !CLRSTACK dumps the managed code on the stack on the CurrentThread. !DumpStack on the other hand dumps both managed and native stack. Lets try !CLRStack now, the output will be like this :

Here I have moved to the call to GetNext method. Hence you can see the GetNext and Main in stack for the command !CLRStack. With additional argument like -p -l produces the result with better output listing all the parameters passes to the method. You can see this represents the first parameter for the method GetNext, as I have told you which holds the object obj (in our case).

Similarly you can use !DumpStack to dump both the native and managed objects and !EEStack to execute !DumpStack on all threads.

To conclude,

This post is just the starting point of your understanding. There are lots of depth in this topic. You can try an excellent article on MSDN magazine here, which talks more on CLR object creation. If you want to know more on internals of .NET, you can also try my Internal Series here.

Thank you for reading, give your feedback.

Stay tune for more.

Internals of Interface and its Implementation

2011-09-24T14:14:00.000+05:30

As many of my followers requested me to write few things that I missed out from the Internals Series, I should continue with it. In this post, I will cover the internals of Interface implementation and mostly talk about explicit interface implementation, as most of the developers seems to be in confusion with it. I hope you will like the post.

Beginning from the basics, Interfaces are the most important part of any application. Interfaces are language construct that does not implement anything but declares a few members upfront. Generally we use interfaces to create a contract between the two or more communication agents. Another important thing that everyone would be knowing already, Interfaces are meant to be implemented. That means whenever you are creating a class, all the members that were there in the interface are meant to be implemented completely. .NET (or probable any other standard language) disallows the creation of objects on types that are not fully defined. Hence abstract classes also coming into play here. They are classes that have few members undefined or abstract. Once you don't have concrete implementation, you cannot create an instance of a type. Notably, you can say "Interface is a types that does not belong to the System.Object or implement it when it reside inside an assembly". But ironically you could also says that once the type is implemented, it would probably inherit from System.object by default.

Another important OOPS feature is that you can hold reference of any concrete type to any of its base implementations. By this what I mean, if say class X derived from Y and implements Z (where Z is an interface) you can say either Y y1 = new X() or Z z1 = new X().

Now lets define an interface and start some tweaks some of its behaviors.

public interface IA
{
    void GetX();
}

Let us suppose we have an interface IA which has a method GetX(). Now you should remember, it is not allowed to use access specifier for members of an interface as that mean the implementers of this interface needs to specify access specifiers for its members and it would appear to all implemtors that these members are public. Now lets see one implementation of it.

public class A : IA
{
    public void GetX()
    {
        Console.WriteLine("Here is X: Normal");
    }
    void IA.GetX()
    {
        Console.WriteLine("Here is X: Explicitely");
    }
}

A is a class which implements IA, and hence need to declare one member GetX. Now you can see here we have defined two implementation of the same method GetX. The other one is Explicit implementation of IA. The explicit declaration of a method can only be done for Interfaces (not allowed for normal classes) and allows you to differentiate the calls to GetX to its explicit implementation when interface is used rather than a normal derived reference is used. Hence if I call :

A a1 = new A();
a1.GetX(); // prints Here is X: Normal

IA a2 = a1;
a2.GetX(); //Prints Here is X: Explicitely

You can see here compiler replaces the call to some explicit implementation based on the reference itself.

There are few basic characteristics of Explictely implemented methods.

They are not overridable and cannot be made virtual.
They can only be called with appropriate interface name, as the methods in Vtable is not determined by its name but by the reference it calls for.
You cannot specify any access specifier for the implementation of Explicit method.}
They remain private and does not belong to a member of actual concrete class. For instance, if I remove the normal implementation of GetX and try calling the code below :
```
dynamic a1 = new A();
a1.GetX();
```
It produces an exception, as A does not contain the member GetX().
Now if we see the IL for the implementation :

So here you can see the explicit declaration defines two important attributes, viz, newslot, virtual and final.

newslot defines a new pointer in the VTable. Thus it is a completely new method created in vtable that can only be called by reference of the interface explicitely.

virtual : you must already know virtual means the object could be overridable at runtime.
final : means sealed.

Hence it is a sealed method with a new entry in VTable.
They are privately inherited and can be implemented only in the class where the Interface is actually implemented, not in any of its parent. For instance :
```
public interface IA
{
    void GetX();
}
abstract class A : IA
{
}
public class B : A
{
    public void GetX()
    {
        ((IA)this).GetX();
    }
    void IA.GetX()
    {
        Console.WriteLine("New Impleentation");
    }
}
```
The above code produces an exception
"Inconsistent accessibility: base class 'TestInterfaceApplication.A' is less accessible than class 'TestInterfaceApplication.B'"

Which means the GetX() method is private to B and cannot be implemented there.
But remember, interface inheritence is supported. Thus the code below compiles fine :
```
public interface IA
{
    void GetX();
}
public interface IB : IA
{
}
public class B : IB
{
    public void GetX()
    {
        ((IA)this).GetX();
    }
    void IA.GetX()
    {
        Console.WriteLine("New Impleentation");
    }
}
```
This is because interface implementation is not actually possible in CLR without marking both of them in concrete class so that the Types can be cast to any of the parent interfaces. So when you specify an Interface implementation, the two interfaces remains as individual types and when you implement the derived interface, it will actually implement the two interfaces for you. Its just a compiler trick. Lets see the IL.

So here you can see, if I implement a Derived interface IB from IA, the actual class actually implements both the interface explicitly.

Practical uses

Explicit interfaces are generally used when you need two implementation of same method or property to co-exist. We generally create Explicit interfaces to specify default behaviour of a class. As explicit methods are actually attached to the interface itself, so at any level of Inherited member, it can be cast easily to get the default implementation (which is in fact not overridable).

Even though there might be some further cases where it comes really handy, I would like to leave them for you. Post your comments regarding some other practical implementation or something you would like to address to me.

Thanks, I hope you find it interesting.

Happy programming.

Writing a Custom ConfigurationSection to handle a Collection

2011-09-12T05:04:00.001+05:30

Configuration is one of the major thing that you need to keep in mind while building any application. Either its an Windows Forms application or a Web site, configuration file is always needed. We write all the configuration that are needed to be changed after it is being deployed in confugration files. It is an XML File which lists all the configuration blocks itself and also allows you to define your own custom configuration sections yourself. Today I am building my own custom configuration section and show how easily you can build yourself.

While dealing with Configurations, there are two things that you need to address

ConfigurationSection
ConfigurationElement
ConfigurationElementCollection

For most of the simple configurations, it is pretty much common to use these two classes, but when you need more complex configuration block, like appsettings which actually puts a Collection of ConfigurationElements, you might need to use ConfigurationElementCollection to hold the collection of ConfigurationElement.

Here in the article I will build one Configuration similar to appsettings so that it would be easier to build one for your own application.

ConfgurationSection maps to the whole configuration, reading through the whole configuration you define in your config file. It has its own serialization and deserialization technique internally to open and close one specific ConfigurationSection when you want. For each Configuration file, it searches the Type of the ConfigSection, (in out case it is ConnectionSection which is within the assembly Configurationsettings). The name of the section indicates the Tag which you use for your ConfigurationSection.

ConfigurationElement maps with the individual element of the Section. It generally points to the entire XML configuration Tag that we use for the configuration. It is the serialized object with all the information about your configuration. When used as a Collection (as in our case) the ConfigurationElement maps to individual configuration blocks (in our case it is Element).

ConfigurationElementCollection : Each ConfigurationSection can have a collection of ConfigurationElement. In our case Servers represents the collection of Element.

Now lets see how we code to retrieve data from this Configuration.

Implementation of ConfigurationElement

On the lowest level, each Configuration block in the collection represents one .NET object. Lets think that the enter tag here is converted to a .NET object and vice-versa. So how your .NET object would look like ?

public class Element : ConfigurationElement
{
    [ConfigurationProperty("name", DefaultValue = "", IsKey = true, IsRequired = true)]
    public string name
    {
        get { return (string)base["name"]; }
        set { base["name"] = value; }
    }
    [ConfigurationProperty("servername", DefaultValue = "", IsKey = false, IsRequired = true)]
    public string servername
    {
        get { return (string)base["servername"]; }
        set { base["servername"] = value; }
    }

    [ConfigurationProperty("isactive", DefaultValue = "true", IsKey = false, IsRequired = false)]
    public bool isactive
    {
        get { return (bool)base["isactive"]; }
        set { base["isactive"] = value; }
    }

    [ConfigurationProperty("userid", DefaultValue = "abhi", IsKey = false, IsRequired = false)]
    public string userid
    {
        get { return (string)base["userid"]; }
        set { base["userid"] = value; }
    }

    [ConfigurationProperty("password", DefaultValue = "password", IsKey = false, IsRequired = false)]
    public string password
    {
        get { return (string)base["password"]; }
        set { base["password"] = value; }
    }
}

Here the class Element represents exactly as we define our Configuration element in the collection. Our Element in configuration looks like :

<Element name="RemoteServer"
                    servername="68.240.22.19"
                    userid="abhijit"
                    password="passcode"
                    isactive="true" />

So our idea to create a type that maps to this. Remember XML is case - sensitive.
Hence we create a class. We map the individual Properties with ConfigurationProperty. You can see each individual property has few attributes that you can define. Such as, DefaultValue would be used whenever the attribute is not present in actual configuration; IsRequired indicate that the property is mandatory etc.

You should always consider one of the property of the ConfigurationElement as Key field. Key field represents the unique identifier for the object.

Implementation of ConfigurationElementCollection

Now as we have a collection of Element in our configuration block, we need to wrap the individual Element inside a ConfigurationElementCollection. This class is an abstract implementation of a ConfigCollection. It has few members that we need to address. Lets see how do we implement it.

[ConfigurationCollection(typeof(Element))]
public class ServerAppearanceCollection : ConfigurationElementCollection
{
    internal const string PropertyName = "Element";

    public override ConfigurationElementCollectionType CollectionType
    {
        get
        {
            return ConfigurationElementCollectionType.BasicMapAlternate;
        }
    }
    protected override string ElementName
    {
        get
        {
            return PropertyName;
        }
    }

    protected override bool IsElementName(string elementName)
    {
        return elementName.Equals(PropertyName, StringComparison.InvariantCultureIgnoreCase);
    }


    public override bool IsReadOnly()
    {
        return false;
    }


    protected override ConfigurationElement CreateNewElement()
    {
        return new Element();
    }

    protected override object GetElementKey(ConfigurationElement element)
    {
        return ((Element)(element)).name;
    }

    public Element this[int idx]
    {
        get
        {
            return (Element)BaseGet(idx);
        }
    }
}

First and foremost, we need to annotate the class using ConfigurationCollection attribute. Generally, each configurationSection is read by the .NET configuration reader using Reflection. It chooses appropriate classes based on the Attribute. Hence it is important to define this for each configuration.

Here the first thing that you notice is we define an Indexer for the class and return BaseGet(index). The BaseGet actually reads the configuration collection and use Reflection to create object of the ConfigurationElement.

Another important thing that you need to address in this implementation is CreateNewElement. You need to return the actual implementation of your ConfigurationElement here. The ElementName represents the name of the Tag that you use in Config file.

Implementation of ConfigurationSection

Finally we need to actually map the collection to a single ConfigurationSection. Lets see the implementation first :

public class ConnectionSection  : ConfigurationSection
{
    [ConfigurationProperty("Servers")]
    public ServerAppearanceCollection ServerElement
    {
        get { return ((ServerAppearanceCollection)(base["Servers"])); }
        set { base["Servers"] = value; }
    }
}

Here basically we create an object of our Collection and return the whole XML block using base["name of the block"]. You must notice that we wrapped the whole configuration inside one XML tag called Servers. We use this to indicate the whole collection.

As a Side Note

Yes, of course you can read configuration directly without using existing APIs available. This article demonstrates how to handle complex configuration blocks for your application.

If you are looking for something simplier than this, check the following links :
3 Easy steps to create Configuration

In much simple scenario you dont need to use ConfigurationSectionCollection rather you can simply use ConfigurationSection itself to handle your entire configuration.

To Get information about Configuration

To retrieve the information of the configuration lets define a class and enumerate all the Element objects that can be found from Configuration.

public class ConfigSettings
{
    public ConnectionSection ServerAppearanceConfiguration
    {
        get
        {
            return (ConnectionSection)ConfigurationManager.GetSection("serverSection");
        }
    }

    public ServerAppearanceCollection ServerApperances
    {
        get
        {
            return this.ServerAppearanceConfiguration.ServerElement;
        }
    }

    public IEnumerable<Element> ServerElements
    {
        get
        {
            foreach (Element selement in this.ServerApperances)
            {
                if (selement != null)
                    yield return selement;
            }
        }
    }
}

Here we use GetSection to get the specific section that we have created, and we can easily cast the object returned by GetSection to ConnectionSection. The GetSection automatically creates the instance of the class (if everything is alright) . Now as our section also contains a Collection of custom settings, we have yield the elements from ServerAppearanceCollection.

Download Source application

Conclusion

Use of Custom Section for app.config is generally very handy. The System.Configuration api exposes a number of good classes that can handle configuration for you. Here I have shown how to create a section that might act similar to AppSettings or any collection oriented settings.

I hope this will come handy.

Thanks for reading.

31 Tips for the month on Threading, WPF, MEF, ASP.NET

2011-09-01T01:49:00.000+05:30

Daily .NET Tips is aiming to sharing useful coding tips and tricks for .NET Developers. This site completely design for sharing Tips and Tricks, useful Code Snippet which anyone use in daily development work and targeted anything related with .NET. This month we have wide range of tips including Threading, MEF, WPF and MVC. In this post I am quickly listing down all the tips which are published over the month August 2011. And the most important point to mention, among those 31 tips that has been posted on DailyDotnettips this month 22 is coming from me.

To get regular updates visit http://dailydotnettips.com and follow @dailydotnettips at Twitter.

I hope you would like the posts. Stay tune for more.

Monday Mornings : Extensibility in .NET 4.0

2011-08-28T14:20:00.000+05:30

It is my great pleasure to speak at Microsoft Moday's last Monday on 22nd August 2011. I have introduced a way to develop a plugin based application with and without MEF. I have also touched some of the interfaces which Visual Studio uses for Extensibility. It has been a very good session and I have learned a lot from it.

If you are a part of the session, please get the Power Point Presentation and the updated source code.

Extensibility in application

View more presentations from Abhishek Sur.

You can download the source code from here.

For further references on MEF you can read :

http://tinyurl.com/MEFWorld

http://tinyurl.com/MEFSource

http://tinyurl.com/MEFGuide

http://tinyurl.com/MEFBlogs

http://tinyurl.com/MEFDiscussions

http://tinyurl.com/PluginMEF

Thanks for attending my session.

Keep in touch.

Steps to write a plugin based application with MEF

2011-08-27T23:38:00.000+05:30

I have already written a blog on Managed Extensibility Framework few days ago, and you must wonder why I am writing again. Well actually today I have been creating an application that could be easily plugged into a host application. In this blog lets show you in steps how you could easily create your own plugin based application and later change itself easily using MEF.

Steps to create a Plugin based application :

Before we proceed lets look how the User Interface for the application that I am building looks like :
The UI contains two Panels, one to show the UI loader control, ideally will list a Button, and another container which will load the actual UI for the application. I have used normal windows based application to make you understand better. Initially it will show you a button, and when you click on the button, it will load the actual usercontrol.
To start creating a plugin based application, we need to create a contract that lies between the Modules and the Host. The contract restricts the Plugins to be loaded on the Host.
Lets add a Class Library to the project and name it as PluginContract. We add 3 interfaces.
```
public interface IProcessRunner
{
    void Process();
}
```
The IProcess interface includes some portion of code that you need to execute when the application is getting loaded. This interface acts as a process which the plugin needs to execute whenever the object is loaded. The idea is to separate the actual process code from the User Interface.

Next we define IPlugin interface which maps the actual User Interface of the Module. The definition of the IPlugin interface looks like :

public interface IPlugin
{
    UserControl GreeterControl { get; set; }

    bool IsPluginCreated { get; set; }
    void CreatePlugin();
    UserControl GetPlugin();

}

The final Interface represents the Interface attacher when connects the plugin with the application and also giving a special interface to run the plugin and run custom code. The interface looks like :

public interface IInterfaceAttacher
{
    Control InterfaceControl { get; set; }
    IProcessRunner Runner { get; set; }
    Control GetInterfaceObject();
    IPlugin Plugin { get; set; }
    Control Container { get; set; }
}

Once you are done, you can add a new Class Library and add one UserControl in it. We call it as GreetControl. Add reference to the Contract library and add the implementation of the interfaces.
IProcess is the most simple interface that I have added to the system. It implements only Process method. The idea is to invoke a sequence of steps in the Process to generate the UserControl. For simplicity we put a messageBox in it.

The IPlugin interface on the other hand actually used to create an object of my plugin and return back the object. The implementation looks like :

public class Plugin : IPlugin
{
    public UserControl GreeterControl { get; set; }

    public bool IsPluginCreated { get; set; }
    public void CreatePlugin()
    {
        if (this.GreeterControl == null)
            this.GreeterControl = new ucGreetMessage();

        //Initialize

        this.IsPluginCreated = true;
    }

    public UserControl GetPlugin()
    {
        if (!this.IsPluginCreated)
            this.CreatePlugin();

        return this.GreeterControl;
    }
}

Here we create the object of GreeterControl and return the object of it when the GetPlugin is called. This contract element should be used from the Host to load the interface.

InterfaceAttacher is created to aggregate all the elements into a single object. It creates an object of IPlugin, an object of IProcess, so it is the main contract for the whole plugin. Lets see how I implement the interface :

public class InterfaceAttacher : IInterfaceAttacher, IDisposable
{

    private void Initialize()
    {
        this.InterfaceControl.Text = "Load Greeter";
    }

    public Control InterfaceControl { get; set; }
    public IProcessRunner Runner { get; set; }
    public IPlugin Plugin { get; set; }

    public Control Container { get; set; }

    public Control GetInterfaceObject()
    {
        if (this.InterfaceControl == null)
        {
            this.InterfaceControl = new Button();
            this.InterfaceControl.Click += new EventHandler(InterfaceControl_Click);
        }
        this.Initialize();

        return this.InterfaceControl;
    }

    void InterfaceControl_Click(object sender, EventArgs e)
    {
        if (this.Container == null)
            throw new ApplicationException("You cannot load a module without specifying the container");

        if (this.Runner == null)
            this.Runner = new Processor();

        this.Runner.Process();

        //Load Plugin
        if (this.Plugin == null)
            this.Plugin = new Plugin();

        this.Container.Controls.Add(this.Plugin.GetPlugin());
    }

    #region IDisposable Members

    public void Dispose()
    {
        if (this.InterfaceControl != null)
            this.InterfaceControl.Dispose();
    }

    #endregion
}

Here the InterfaceControl is an individual control which will be loaded on the system and used to invoke a load operation of the Plugin. Here for simplicity I have used a Button to load the plugin, but ideally it should be a menu item. Thus when the object is Clicked, it will invoke certain events to call the Process of IProcess and load the IPlugin to the Container which is provided by the Host.

Certainly, you might be thinking why I am showing this crappy unusable code to you. Actually I have written this code long ago, may be at least 2 years ago when I was actually creating plugin based application for the first time. Here is to show you how I have actually developed the system, and how easy is to modify it to use MEF.

Creating the Host

Finally lets create the Host for this Plugin. The plugin host will host two container (in our case) one to load all the buttons that are coming for each individual plugin which loads the actual plugin to the system, and another is to host the actual plugin interface. Lets take two panels in the Form and name it pnlLoadControls for the panel which loads the InterfaceLoader (Button) and pnlContainer which loads the actual UserControl coming from plugin.

Once the interface is created we need to write some code to actually load all the interface elements when form is loaded and upon user interaction, the actual UserInterface is loaded. Hence we write like this :

private void Form1_Load(object sender, EventArgs e)
{
    foreach (string fpath in Directory.GetFiles("plugins", "*.dll"))
    {
        this.LoadAssembly(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, fpath));
    }
}

private void LoadAssembly(string filepath)
{
    Assembly asm = Assembly.LoadFile(filepath);
    var items = asm.GetTypes().Where(t => typeof(IInterfaceAttacher).IsAssignableFrom(t));

            

    foreach (var item in items)
    {
        IInterfaceAttacher attacher = Activator.CreateInstance(item) as IInterfaceAttacher;
        attacher.Container = this.pnlContainer;
        this.pnlLoadControls.Controls.Add(attacher.GetInterfaceObject());
    }
}

Hmm, looks quite complex to you, isnt it ? Its just a code that loads the assemblies from the plugins directory and GetInterfaceObject from all the IInterfaceAttacher type that is found within the plugin. Hence the code will place the button called Load in the interface. You can see, that we pass the Container to load the actual interface when the InterfaceControl is clicked.

So this is all we need to create our first plugin based application.

Limitations of this approach:

This approach is very tightly coupled with the host. The Plugin needs to follow exactly what the rules that is created by the Host.
The plugins are not flexible enough to create interdependencies. That means, you cannot have interdependent plugins so that one plugin can easily host a component coming from another plugin.
The approach requires some sort of standardization so that once a plugin is created it can be re used in another host.
The approach forms a strict rule that a Plugin cannot spread itself in multiple dlls. I mean the IPlugin should always reside within the Plugin attacher.

To address these situations we use MEF.

Lets introduce MEF to the System

If you are new to MEF, please feel free to read my previous blog about MEF to get the idea. MEF is actually a IOC container that relate each Exports with Imports. The idea of MEF is to mark an interface with Export when it needs to be plugged in to a system, and Mark as Import when we need to host some sort of plugin that might be present in the system.

Export:

We mark all methods, properties, types as Export when we want to export the functionality to the external world.

Import

If you are a host of Plugin you need to Import the plugin. Hence Import is used to import a functionality to the system.

Compose

The CompositionContainer is a IOC container that maps individual Export with its appropriate Import.

You can read about them from my article here.

Steps to change the existing application to use MEF

Add System.CompositionModel.Composition to your Plugins and add Export attribute to the IInterfaceAttacher.

Adding Export(typeofIInterfaceAttacher) will enable that the Interface object will be viable to export from the system to some external agent which wants to import it.
In the Actual Host we add a new class which creates a property of IInterfaceAttacher and Import the object. The class looks like :
```
public class InterfaceBuilder
{
    [ImportMany(typeof(IInterfaceAttacher))]
    public IEnumerable<IInterfaceAttacher> Attachers { get; set; }
}
```
We use ImportMany as we can have multiple plugin in the dlls. So the property Attachers will list all the plugins into a single IEnumerable.
In the Form, lets remove all the code that I have written to invoke the Type from assembly and change it to something like this :

private void Form1_Load(object sender, EventArgs e)
{
    DirectoryCatalog catalog = new DirectoryCatalog("plugins");
           
    InterfaceBuilder builder = new InterfaceBuilder();
    CompositionContainer container = new CompositionContainer(catalog);
    container.ComposeParts(builder);


    foreach (IInterfaceAttacher attacher in builder.Attachers)
    {
        this.pnlLoadControls.Controls.Add(attacher.GetInterfaceObject());
        attacher.Container = this.pnlContainer;
    }
}

Now if you run the code, it runs just fine.

Thus you can see that the Exported plugin is actually created automatically using CompositionContainer and works as we have implemented earlier.

Benefits ?

Yes. There are lots of benefits of using MEF.

As it forms a standard, the same dll can plugin to any system that imports something that the plugin is going to export.
As we do not create dlls manually and rely completely on CompositionContainer, it is quite capable of handling errors, and reporting critical errors.
Interdependency can also be achieved in this approach. The plugins can spread into multiple dlls easily. Lets look how :

We made the Runner and Plugin in InterfaceAttacher as Import capable and removed the object creation from InterfaceControl_Click event handler. And Export the actual classes. Even you can do the same for the UserControl too.

Simple huh ?
Yes now you can spread the types into assemblies, even your plugins can import types from outside the assemblies, even from the host

You can download the sample

I hope this post comes to you handy. Even though you should change it in your practical plugin based application, but this will help you to start.

Thank you.

.NET Tips : List of my short tips

2011-08-15T01:13:00.002+05:30

Hi Friends,

As I have already told you that I have been publishing short tips in DailyDotnetTips regularly, it is time to share the links with you to keep you updated. Please read these short tips from me and give your feedback.

So here are my last 20 short tips posted on DailyDotnetTips.

I hope you will like these tips. For full list of all the tips and the latest updates, check this link.

Happy Coding.

Thanks.

Internals of Dependency Property in WPF

2011-07-31T05:35:00.000+05:30

WPF introduces new property system to us. Every WPF objects that is inherited from DependencyObject inherently supports Dependency property containers within it. That means you can define your own dependency property in your code which can take part in some of the interesting features of WPF like Binding, Styles, Triggers, Animation, Property Inheritence etc. Today I will concentrate on how Dependency Property system is actually built and what are the benefits we get instead of using CLR property system.

Note : If you are really new in WPF and don't know about Dependency Property, it would be nice to read my post on Dependency Property or you can also try WPF Tutorial series to start on.

So lets start on using the most basic code of creating your own Dependency Property.

public static readonly DependencyProperty DescriptionProperty = 
    DependencyProperty.Register("Description", typeof(string), typeof(DependencyHoster));

public string Description
{
    // Will not be called each time property is retrieved. Only be called when 
    //you explicitely call it through ur code.
    get
    {
        return (string)this.GetValue(DescriptionProperty); 
    }
    set
    {
        this.SetValue(DescriptionProperty, value);
    }

}

So here we define a property called Description to our DependencyObject named DependencyHoster of type string. According to the rule specified on DependencyProperty System, it is stated that you should always create a static reference of DependencyProperty and call Register to register a property to the Property System. It is also to the rule, that you should define a CLR property Stub which will call GetValue and SetValue in its getter and setter which is defined in DependencyObject to get or set the actual value defined for the instance. The Dependency property reference should be named with property name with "property" suffix. (in our case property name is Description and with suffix Property, it is named as DependencyProperty).

Now lets see what exactly happens inside when you Register a DependencyProperty. I would use our favorite tool Reflector to get deep into it.

So if you look into the Register method you will see something like this :

Now lets concentrate on the lines highlighted in the image. The First creates an object of FromNameKey, which is created with name that we pass in Register and the Type in which the key is associated with. This class is just a repository of a single key element with the type associated with it.

Next, it is checked inside a HashTable named PropertyFromName. Well, I don't know why it is used as HashTable rather than Dictionary, may be because both Key and Value of the object is Reference Types and does not need boxing/unboxing.

Another important line that actually assigns the new object of DependencyProperty to the HashTable.

So basically from the above three lines, you can deduce some of the interesting facts on DependencyProperty System as of now :

A DependencyProperty maintains a static reference of all the DependencyProperty you register in WPF object hierarchy. It maintains a HashTable named PropertyFromName which it uses internally to get the DependencyProperty object. So in other word, each dependencyProperty object is registered in a global HashTable.

Now lets check the object DependencyProperty as a whole and what it is capable of. Remember that each DependencyProperty object is created once for every DependencyProperty you define in your property system and not on every instance of object you create. Hence according to what we just seen, all TextBox will have only one TextProperty dependency property that go inside the field PropertyFromName.

Therefore the object DependencyProperty just holds the name, ownerType and its metadata. Metadata can be the Callbacks the DependencyPropertyKey element etc.

Where the value gets stored exactly ?

Well this might have come already in your mind. As I have already seen the DependencyProperty and it seems nowhere until now, a provision of value to be stored, yet a DependencyProperty has a method called GetDefaultValue for a specific type which will return the default value, but what if I assign something to a Type, where does it get stored ?

To clear this confusion, lets look into DependencyObject instance a bit and try to see what exactly written inside GetValue, SetValue and ClearValue method.

1. GetValue

GetValue is used to get the current value of an instance of a control. Remember, DependencyProperty supports a number of levels in which the effective values could be retrieved. Lets look in detail on the source of GetValue.

The code snippet that I have specified,clearly says that every DependencyObject instance actually maintains a collection of objects (EffectiveValues) which will be set only when the instance stores / modifies the value of the DependencyProperty. The code gets either from the own collection or gets it from a method GetEffectiveValue based on whether the Request is fully resolved or not. the GetEffectiveValue identifies whether the current value is in animation mode (DependencyProperty supports animation) or is in Expression.

Finally it checks whether the dependencyProperty DefaultValue is changed or not. If it isn't it gets you the default value of the property.

2. SetValue

SetValue on the other hand actually sets a value of a DependencyProperty on the instance from which it is called. As we have already seen every DependencyObject actually maintains a collection of EffectiveValueEntry which holds the value of instance object we specify with some index value.

So the first thing that you notice is inside the SetValue is actually a feature. If you pass DependencyProperty.UnsetValue as value, it will actually call ClearValue for you. Hence SetValue(DP, DependencyProperty.UnsetValue) equals ClearValue(DP).

The rest of the code looks quite simple. It checks whether the entry exists in the current object, if so it resets the value or it create a new EffectiveValueEntry and store it and update the index.

Impact of Styles

If you look into styles, it just maintains a collection of Setter. A setter on the other hand maintains a combination of DependencyProperty and the Value of the dependency property. Hence when a style is applied on an instance, it will get the value from it.

The Style is actually a DependencyProperty defined inside FrameworkElement class. So in object hierarchy, it gets the value of the Style. Once the style is set for a control, it first clears all the object instances that the object already applies to and then apply the setters to each of them.

Thus the CreateInstanceData is used to apply a new style for a type.

Remember, styles are overridden by the object values during runtime.

Summary

To summarize,

Dependency Property System holds a collection of all DependencyProperty with its corresponding ownerType.
Each instance of a DependencyObject holds a collection of all individual DependencyProperty that has been changed either through animation or programmatically.
Styles produce a separate entity that holds a Key Value collection of a DependencyProperty and its value, once it is applied to a FrameworkElement, it modifies the default DependencyProperties with the ones that is defined inside styles.
Separating DependencyProperty from the object instance saves lots of space, as Reference Types will not create object instances when each instance is created, but will use up the existing instance every time. The separation of property system also allows to have a Property to be used as attached to its children.

Conclusion

There are lots of things to be learned and lots of things to be talked about in this regard. It is just the beginning.

Feel free to comment. I would love to see if I missed out something or if anything that you didnt like.

Read more about internals from my Internals Series.

Thanks for reading.

Writing a Reusable Custom Control in WPF

2011-07-24T22:19:00.002+05:30

In my previous post, I have already defined how you can inherit from an existing control and define your own reusable chunk. The reusable XAML code that I have defined there is actually a composition of one of more existing elements in a common design surface. But sometimes you must define a new behaviour for your reusable component which does not belong to any of the already existing behaviors. Custom controls can help you in this. You can define a new behaviour for your Custom control which can have a default look and feel defined for it, and obviously which can be changed using Template for the user who is using the control. In this post I am going to provide you step by step approach on defining a Custom Control for your application.

Note: If you are really new to WPF, please read my WPF Tutorial before going further.

Steps to Create a new Custom Control

Creating a custom control is very simple. Just in your project right click and add a new Item. In the dialog box that appears, choose Custom Control template and Name it. I call it here as SimpleControl.

Once you have added the control, it adds up a new class to your project which inherits from Control. The Template also provides you with some initial help to define your own control. Lets remove all the comments for now and start building a control.

Download Sample Code

In this control, I will show you all the components that you need for a Control so that it would help you guide each of the components individually.

Components that comprises a Custom Control

There are a number of components that you need to use inside your custom control which represents the behaviour for your control. Lets define each of them one by one before creating a Control.

1. Property : Properties are one of the most important component for a control. In WPF, we use properties to define certain characteristics of a control. You can use either CLR properties or a Dependency Property. As you must know already a dependency property is a new Property System introduced with WPF, which holds a container of all the properties you define for a single instance of your control and which supports Property Value Inheritence, Animation, Templates, Styles, etc. To read more about Dependency Property check my article.

Example :

public static readonly DependencyProperty ColorProperty = DependencyProperty.Register("Color", 
    typeof(Color), 
    typeof(SimpleControl), 
    new PropertyMetadata(Colors.Green));

public Color Color
{
    get
    {
        return (Color)this.GetValue(ColorProperty);
    }
    set
    {
        this.SetValue(ColorProperty, value);
    }
}

Here we have defined a new dependency Property called color, which will represent the initial BackColor of the control. The Default value for the Property is defined as Green.

2. Commands : It is important to define a command for your Control rather than using a method. Commands lets you use CommandBinding on a control just like your Button Class. The Command generally invoke certain set of action defined using ICommand interface. It also creates an Inversion of Control to invoke some user code as well, during the event.

Example :

static SimpleControl()
        {
            CommandManager.RegisterClassCommandBinding(typeof(SimpleControl), 
                new CommandBinding(SimpleControl.CustomCommand, OnCustomCommand));
        }

        static void OnCustomCommand(object sender, ExecutedRoutedEventArgs e)
        {
            //Need to first retrieve the control
            SimpleControl invoker = sender as SimpleControl;

            //Do whatever you need
        }

        public static readonly ICommand CustomCommand = new RoutedUICommand("CustomCommand", "CustomCommand",
                                                        typeof(SimpleControl),
                                                        new InputGestureCollection(
                                                            new InputGesture[] { 
                                                                new KeyGesture(Key.Enter), 
                                                                new MouseGesture(MouseAction.LeftClick) }
                                                                )
                                                          );

Here I have defined a Command called CustomCommand. As you can notice I have used Static Constructor to register my command and static eventHandler so that it is more efficient. You can easily retrieve the actual object easily from sender.

3. RoutedEvents : Events are another most important thing for a control. You can define your own event for the control, but it should be RoutedEvent to ensure that WPF model supports them internally. RoutedEvent supports event routing, that the event can bubble or tunnel to the complete Visual Tree, when the event is raised. The FrameworkElement has a complete set of methods to use in defining a RoutedEvent.

Example :

public static readonly RoutedEvent InvertCallEvent = EventManager.RegisterRoutedEvent("InvertCall",
    RoutingStrategy.Bubble, typeof(RoutedEventHandler), typeof(SimpleControl));

public event RoutedEventHandler InvertCall
{
    add { AddHandler(InvertCallEvent, value); }
    remove { RemoveHandler(InvertCallEvent, value); }
}

private void OnInvertCall()
{
    RoutedEventArgs args = new RoutedEventArgs(InvertCallEvent);
    RaiseEvent(args);
}

Just like dependency property system, WPF event system also holds a collection of Events which appropriately raises the event for a particular control when some specific operation is executed. The WPF event system can take part on EventSetters, Triggers etc. You have noticed that you can use Addhandler and RemoveHandler from the Event Accessor to add or remove an event for a particular control. The RaiseEvent is used to raise an event for a particular control.

4. Handling an Event : Sometimes your control might require to handle an Event that already comes from Control. For instance, the Button class handles an event called MouseDown to create an event Click to it. In such a scenario you can use RegisterClassHandler method to handle an event.

Example :

static SimpleControl()
{
    EventManager.RegisterClassHandler(typeof(SimpleControl), Mouse.MouseDownEvent, new MouseButtonEventHandler(OnMouseDown));
}

static void OnMouseDown(object sender, MouseButtonEventArgs e)
{
    SimpleControl invoker = sender as SimpleControl;
    //Do handle event

    //Raise your event
    invoker.OnInvertCall();

    //Do Rest
}

Now here I have used RegisterClassHandler to handle the event. This will handle the MouseDown event for the control and invoke InvertCall event defined as RoutedEvent.

5. TemplatePart : For every control you should specify the rules how the UI for the control should look like. Template allows the user of your control to modify the look and feel, but using TemplatePart you can define the part of a control which you can change behaviour from within the control. Say for instance, if your control has a border, and your control wants to change its color when Mouse is hovered over the control, you can call the part attribute to apply this change which will be shown for any Template your user define later on, provided it should name the same part name.

Note: Currently PartNames are not actually checked for Templates, so you can omit a part
Example :

[TemplatePart(Name="PART_MainBorder", Type=typeof(Border))]
[TemplatePart(Name="PART_body", Type= typeof(ContentControl))]
public class SimpleControl : Control
{

    Border MainBorder;
    ContentControl Body;

    public override void OnApplyTemplate()
    {
        base.OnApplyTemplate();

        if (this.Template != null)
        {
            Border mainBorder = this.Template.FindName("PART_MainBorder", this) as Border;
            if (mainBorder != MainBorder)
            {
                //First unhook existing handler
                if (MainBorder != null)
                {
                    MainBorder.MouseEnter -= new MouseEventHandler(MainBorder_MouseEnter);
                    MainBorder.MouseLeave -= new MouseEventHandler(MainBorder_MouseLeave);
                }
                MainBorder = mainBorder;
                if (MainBorder != null)
                {
                    MainBorder.MouseEnter += new MouseEventHandler(MainBorder_MouseEnter);
                    MainBorder.MouseLeave += new MouseEventHandler(MainBorder_MouseLeave);
                }
            }

            Body = this.Template.FindName("PART_body", this) as ContentControl;

        }
    }

void MainBorder_MouseLeave(object sender, MouseEventArgs e)
{
    Border thisBorder = sender as Border;
    if (thisBorder != null)
    {
        thisBorder.Background = new SolidColorBrush(Colors.Red);
        if (Body != null)
        {
            Run r = new Run("Mouse Left!");
            r.Foreground = new SolidColorBrush(Colors.White);
            Body.Content = r;
        }
    }
}

void MainBorder_MouseEnter(object sender, MouseEventArgs e)
{
    Border thisBorder = sender as Border;
    if (thisBorder != null)
    {
        thisBorder.Background = new SolidColorBrush(Colors.Blue);
        if (Body != null)
        {
            Run r = new Run("Mouse Entered!");
            r.Foreground = new SolidColorBrush(Colors.White);
            Body.Content = r;
        }
    }
}

So here I have created two TemplatePart one named PART_MainBorder and another PART_body. In your Generic template you must define this TemplateParts so that the default control acts perfectly. The User can also redefine the template and once the user redefines it, it can also use these Part names to call a specific control inside, so that your control can apply something inside of it. In this example I have used a border, which will change its color to Red when Mouse is entered inside of it, and to Blue when it is left. You should note that I have used Template.FindName and passed the current instance of the control. This is important because Templates are generally shared by more than one instance.

When a Template is applied to a control it calls OnApplyTemplate. Make sure you are tolerant enough to handle bad templates, as you can see, I have checked every time if the object is available before doing anything with it as WPF ignores bad templates and your control might end up with a bad NullReferenceException somewhere if you dont gracefully eliminate the same.

Now in your actual Window, you should declare the template for the Control and define each of the PartNames you specify here.

6. Themes : Yes your control should define a default Theme at least to make sure it at least appears when an object is created. At the basic level, when you add a new Custom Control to your project, you should add a style for Generic.XAML that is added up on the Themes folder. The AseemblyInfo also adds up a assembly level attribute which identifies where the default Theme template resides.

The Theme folder will by default hold a Generic.xaml. Lets add a default Style for our control.

<Style TargetType="{x:Type local:SimpleControl}">
    <Setter Property="HorizontalAlignment" Value="Center" />
    <Setter Property="VerticalAlignment" Value="Center" />
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="local:SimpleControl">
                <Border x:Name="PART_MainBorder" Width="{TemplateBinding Width}" Height="{TemplateBinding Height}">
                    <ContentControl x:Name="PART_body" 
                                    HorizontalAlignment="{TemplateBinding HorizontalAlignment}" 
                                    VerticalAlignment="{TemplateBinding VerticalAlignment}" >
                    </ContentControl>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Now as you can see this is a simple Style that will be applied to each control we instantiate in our application.

Creating the Sample

Now as we have already created our control lets add this control in MainWindow.

<Window x:Class="CustomControlExample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:CustomControlExample"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition />
        </Grid.RowDefinitions>
        <local:SimpleControl Width="90" Height="90" >
        </local:SimpleControl>
        <local:SimpleControl Width="90" Height="90" Grid.Row="1" Color="Crimson">
            <local:SimpleControl.Template>
                <ControlTemplate>
                    <Border x:Name="PART_MainBorder">
                        <Button x:Name="PART_body" HorizontalAlignment="Center" VerticalAlignment="Center" Background="Black"></Button>
                    </Border>
                </ControlTemplate>
            </local:SimpleControl.Template>
        </local:SimpleControl>
    </Grid>
</Window>

So here basically I add two controls in two rows of a Grid. The first one taking up the Default Template it provides, and the second one creates its own template. You can specify the Template Part in your own template as shown in the declaration which interact with the control itself.

Now if you run the sample it shows two rectangular box, one with all default values and another with custom template.

Bit Further

There are also few things that deals with Design Support of Visual Studio and Expression Blend for a control. You can either build separate dlls for design time support for your control with .design.dll or within the same assembly. The design time support can add custom Adorners which can help in layout the control in Visual Designer or Expression Blend. To build a design time support for a control you need to inherit from IRegisterMetaData and build an AttributeTableMetaData, which will work for the Designer. I will talk about it later in a separate post.

Download the Sample Code

Conclusion

You should remember, creating a Custom control does require a lot of effort. So if you looking for just look and feel, you can get a workaround to this using custom template or inheriting from other existing Controls. But if you are building your own Custom behaviour or a library of control, then you should go for Custom Control. Also remember, custom control is Themable, Templatable and also supports inheritence, so you should always consider writing your control gracefully and hitting every possible aspect that your control might come across.

I hope this sample code will help you. If you want, you can read my WPF Tutorial too from here and subscribe to my blog too.

Thank you for reading.

Writing a Reusable WPF Control with Design Support

2011-07-23T22:47:00.002+05:30

Code reusablity is one of the major concern to many of us. When dealing with large projects, modularizing your project is one of the primary thing that you should look for. I have talked about many of the approaches that you can use to deal with modularizing your code, eg, Prism. In this post our intent is not to talk hard on some pattern, rather I will discuss how your WPF application supports code reusability. There are a number of approaches that WPF supports to deal with reusable component. We can use Resources to define a Resource or even use CodeBehind to write our reusable component or even load the XAML from a file using XAML Loader. Each of the approaches has its own pros and cons. Today I will show you another cool technique to write a reusable XAML for your project which will allow you to easily use Visual Studio design surface to design the component.

Note : It is a very basic article, if you want to know about details on WPF, please read my tutorial on it.

Steps to Create your Reusable Component

Lets create a series of steps to create a reusable component for your application to make it easier for you to write one yourself.

Step 1 : Start Visual Studio and Create a new WPF project.
Step 2 : Add a new Page to the application and call it as GreetPanel. Just like the figure below.

Once you are done lets change the code for the Page.

Step 3 : Change the root element of the page to Grid to make it a Reusable grid.

Note : Currently there is no Visual Studio File Template for writing a loose XAML component, hence I have used Page to do the same.

Step 4: After doing this, you also need to go to the Code -behind for the Page and change it to inherit from Grid. Now you have a complete reusable component (UserControl) which can use the design surface too, to define its components.

Now lets define the control with most basic code :

<Grid x:Class="WritingLooseXAML.GreetPanel"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid.RowDefinitions>
        <RowDefinition />
        <RowDefinition />
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
        <ColumnDefinition />
        <ColumnDefinition />
    </Grid.ColumnDefinitions>
    <Label Grid.Row="0" Grid.Column="0" >
        Write Name
    </Label>
    <TextBox Grid.Column="1" x:Name="txtName" />
    <Button Content="Greet Me" Click="Button_Click" Grid.Row="1" Grid.Column="0" />
    <TextBlock x:Name="tbResult" Grid.Row="1" Grid.Column="1"/>
    
</Grid>

Here I define a TextBox and a Button which has a click Handler too. You can define the ClickHandler in the codebehind for the GridPanel too. The Button will display a message in a textblock called tbResult.

The Codebehind looks like :

public partial class GreetPanel : Grid
{
    public GreetPanel()
    {
        InitializeComponent();
    }

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        this.tbResult.Text = string.Format("Hello {0}, Welcome!", this.txtName.Text);
    }
}

Step 5 : Now once you are done defining your GridPanel, you can use it in any Window. Just use xmlns to declare the namespace for the control, here I used the local namespace, and define the controls.

<Window x:Class="WritingLooseXAML.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:WritingLooseXAML"
        Title="MainWindow" Height="350" Width="525">
    <WrapPanel Orientation="Horizontal">
        <local:GreetPanel x:Name="gPanel1" />
        <local:GreetPanel x:Name="gPanel2" />
        <local:GreetPanel x:Name="gPanel3" />
    </WrapPanel>
</Window>

You can access each properties of the Grid from your GreetPanel as it is derived from Grid. Now compile your code and run, you will see your greetpanel working.

Adding a RoutedEvent on the control

As you know RoutedEvent is one of the base for events in WPF application, lets see how you can add one on the panel just declared. Now as you might already know that RoutedEvent can be of three types, one that Bubbles, one Tunnels and one Direct. To declare a RoutedEvent, you need to use EventManager.RegisterRoutedEvent. This command will register the event to the XAML and hence allows you to use Event in EventSetters, styles etc.

In our previous code, lets add an event which will fire when the Result box is altered. To do this, lets add this to the code page of GreetPanel.

static readonly RoutedEvent ResutlAlteredEvent = 
    EventManager.RegisterRoutedEvent("ResultAltered", 
    RoutingStrategy.Bubble, 
    typeof(RoutedEventHandler), 
    typeof(GreetPanel));

public event RoutedEventHandler ResultAltered
{
    add { AddHandler(ResutlAlteredEvent, value); }
    remove { RemoveHandler(ResutlAlteredEvent, value); }
}

// This method raises the ResultAltered event
void RaiseResultAlteredEvent()
{
    RoutedEventArgs newEventArgs = new RoutedEventArgs(GreetPanel.ResutlAlteredEvent);
    RaiseEvent(newEventArgs);
}

private void Button_Click(object sender, RoutedEventArgs e)
{
    this.tbResult.Text = string.Format("Hello {0}, Welcome!", this.txtName.Text);
    this.RaiseResultAlteredEvent();
}

Now from the MainWindow.xaml (where you add this control you can find the ResultAltered event directly.

<WrapPanel Orientation="Horizontal">
        <local:GreetPanel x:Name="gPanel1" ResultAltered="gPanel_ResultAltered" />
        <local:GreetPanel x:Name="gPanel2" ResultAltered="gPanel_ResultAltered" />
        <local:GreetPanel x:Name="gPanel3" ResultAltered="gPanel_ResultAltered" />
    </WrapPanel>

And in the code-behind we added the eventhandler as :

private void gPanel_ResultAltered(object sender, RoutedEventArgs e)
{
    GreetPanel panel = sender as GreetPanel;

    MessageBox.Show(string.Format("You have altered result of {0}", panel.Name));
}

Thus when the button is clicked on the Control it shows up a messagebox shows up.

Conclusion

By this way you can derive any control directly from an existing control. But if you are likely to build a completely new control you can use UserControl as its base, which will ensure that the UI has nothing. This is very easy. In my next post I will talk about Custom Controls.

I hope this tutorial helps you.

Thank you for reading.

ValueType and ReferenceType : Under the Hood Part 2

2011-07-17T01:20:00.000+05:30

Well, if you have read my previous post, you should be already clear how memory of ValueTypes and ReferenceTypes are allocated and De-allocated internally in terms of IL. Here in this post, I am going to cover some more concepts behind ValueTypes and ReferenceTypes and what exactly comprises of them.

In my previous post on the series, I have told you that any type that inherits from System.ValueTypes is stored in Stack while any type that is not inherited from System.ValueType is stored in Heap. Well, the statement is not correct totally.

Lets demonstrate this with an example:

public class MyType
{
    int x, y;
}
public struct MySType
{
    MyType typ;
}

In the above code, I have created two types, 1 being MyType which is a Type directly inherits from System.Object and the other being struct MySType which is derived from System.ValueType. As per our previous discussion you can say, MyType will be allocated in Heap (as it uses newobj of IL) and MySType will be created in Stack being a ValueType (as it uses initobj)

But what about its members?

Class MyType contains two members x and y which are ValueTypes while on the other hand MySType contains a member of MyType which is not a ValueType. So, Where it is going to be allocated?

Well, don't be so much confused about it. Actually while I talked about initobj in my previous post, I have already specified that it will initialize the struct with all its members with default values. Hence when initobj is initialized the value of typ will be assigned to null. At least default constructor for the ValueType does that automatically. But how does it work when we assign an object on it?

Yes, even though MySType is actually a struct, it creates object using newobj IL statement and hence will be stored in Heap. The constructor for MyType will be called and will store the object in heap and get the reference of it in stack. of MySType itself being stored in stack will hold the Reference to the object of MyType in stack, but the actual object does not.

On the contrary, MyType being a Class, it always store the object in heap. Being x and y the member of the type MyType, they are stored in heap itself. As the members of an object comprises the size of the object each of its members will be stored in Heap together.

Thus the actual statement should be "Only local variables are stored in Stack if it is a value type, any other member is stored in heap". Managed environment prefers Heap than stack even though stack is high performance because stack size is limited.

Impact of new operator over Types

Even though we all know about new operator when using reference types, "new" Operator has an important impact overValueTypes which most of people I see does have confusion. Lets clear it with an example.

Lets say I write something like :

MySType s = default(MySType);
s = new MySType();

Console.WriteLine(s);

Console.ReadKey(true);

So here in the code you can see I have created an object of MyType and initialized to its default value which is also implicitly invoke default constructor. In the second line the object of MySType is again created using new oprator. So what does it mean? Does it mean that the memory s is created twice ? Or new operator does not actually create a memory and use up the existing one?

Lets see the IL now :

Basically if you consider the above code, you can see that there is only one reference of local valuetype reference is created, but yet there is two initobj call in the code. So internally there will be two objects been created in your code.

Lets make it more confusing using :

MySType s = new MySType();

Console.WriteLine(s);

Console.ReadKey(true);

And the output to this code is identical to what I showed earlier. Hence in case of ValueTypes you should remember, if you are using any constructor it will first initialize the object using default constructor of struct and pass the same to the constructor as this. Later it will create another object of S and copy the value of temporary variable to it. This is fact.

Hence if you are using a constructor for your stack, internally IL will create more than 1 object of your struct and assign the initialized object to the local storage in stack. Hence "new" operator on stack always creates a new object even though it is of type Struct.

So you can say all the local variables that you declare inside your own code block which are not member of a class are always allocated in stack? Right ?

Wrong!!! .. It is not always true!!!

If you think of an iterator block, or a lambda expression, or even our new async member function, the local variable here is actually mapped to a class in IL. Hence the local variable that you declare inside an iterator block is actually a member of some type in your compiled assembly. Hence local ValueTypes inside your iterator block is not allocated in Stack and not for lambda or async members.

Conclusion

So as to conclude this long talk lets put some points :

Stack and Heap are the primary storage location of any .NET program. (Although it use storage registers too at times).
Anything that is derived from ValueType and declared locally is sometimes allocated in Stack (with exceptions on iterator block, lambdas, async methods)
Any type other than ValueType is allocated in Heap and a separate reference variable is created in Stack to use it. The Object will not be deallocated when de-referenced rather will have to rely on GC to collect them.
Class Members are actually a part of a Type is stored in Heap.
ValueTypes are not nullable and immutable (with exception to string...) while Reference Types are nullable and generally mutable.
A Value Type is passed by Value (means will copy itself in new memory) when passed to another method, Reference type will be passed as Reference (while the Reference variable is newly creates which copy the address of the Heap)

I hope you have found good time reading this post.

Keep posting your feedbacks.

Thanks for reading.

ValueTypes and ReferenceTypes : Under the Hood

2011-07-16T17:01:00.003+05:30

In .NET, Value Type and Reference Types are forms an element of confusion between both developers and the students. Many of us take this as granted that Value Types are allocated in Thread Stack ( a 1 MB local stack created per Thread) and on each method calls the local value types are allocated in the Stack such that after the call ends, the object is deallocated. On the contrary, the reference types we know are those which are always allocated in heap (which is not always true, I will discuss later) and even though they are used as locals, and will be deallocated only after an interval by a separate Thread that is running with any .NET process (called finalizer thread) which occationally starts finding the memory blocks on Heap storage and compact and store only the reachable objects called Garbage Collector. Well, in this post, I am not going to cover the details of Garbage Collection, but rather I will focus more on Value Types and Reference Types that I know personally to clear any doubt regarding them in terms of IL constructs. So after reading the post, you will know some of the basics of IL too.

To tell you the truth, I have been trying to start blogging on this topic long ago, but could not get chance to finish it, but as my buddy @ZenWalker asked me a couple of questions, which I had to answer, I considered myself writing a blog on the same such that it benefits both him and all other people. His questions sounds like this :

If System.ValueType inherits System.object, then all valuetypes are object. right?
If so,
1) Why do we say c# isnt pure Object Oriented because Value Types are not objects.
2) Value Types gets created over stack because to save space over heap or may be for performance right because heap creation takes time.
3. Why are Value Types struct and not class if they both are objects. To avoid complexity for simple types??
4. Why we have to do boxing and unboxing if valuetypes are objects too, or just to copy from stack to heap n back on??

Well the questions sounds quite interesting to me to answer and lets answer then knowing whats going on under the hood of a normal C# application and lets demonstrate them with code.

Lets start a console application and write a code like below :

int x = 10;

object y = 10;

string s = string.Format("x :{0}, y : {1}", x, y);

Console.WriteLine(s);
Console.ReadKey(true);

This is basically very simple code, where I first created one ValueType (int) an object y which is a reference type and formatted them into a string variable and loaded the string into string variable s.

Now let me see how the IL for the same looks like :

Now here lets take a look at the IL. The line says .entrypoint. EntryPoint identifies the start of the program. So if you declare your method as Main in .NET, the entrypoint will automatically be written on it. So it is also a compiler trick which writes the .entrypoint correctly.

The second line says .maxstack 3. Here maxstack will indicate that the method allocates 3 units of stack for the current method. For our code, it will be

1. To store the integer value.
2. To store reference to the type y while the value is stored in Heap.
3. To store the reference to the type s while the value is stored in heap.

Hence you should remember, even though you create an object or a memory block that is allocated in Heap, the reference pointer is still allocated inside your stack, which de-reference itself once the code execution ends. When all the references to a memory is de-referenced, it is exposed to the GC for collection.

So the next statement creates three locals for the code block in stack. locals indicates the stack allocation.

Now lets skip the first expression and concentrate only on the lines highlighted.
stloc.0 : means store the value that is loaded in memory to 0th location of Stack. The line just above it says ldc.i4.s 10, which loads 4 bit integer variable (i4). So the two lines indicates that the value of 4 bit integer will get stored into stack. So without all those complexity, you can say, the two lines will actually initialize the value 10 to the Stack locals 0th location (which infact an integer).

The next highlighted lines indicates a box on Int32. Box means your program will store /convert the loaded value into a reference. Or in other words, the line box will create a storage of 4byte in process Heap and store 10 over it and load the Reference of the Heap to memory. The next line will store the reference to the Heap to the Stack.

Finally, the last three highlighted lines indicates that the locals are loaded into memory again from 0th position and 1st position, where the 0th position holds the value itself, and 1st stored the reference, and box the 0th position to pass in string.Format static method call.

So upto this point you must be clear that "Each valueTypes are actually stored into stack, while Reference Type are stored in some other place (called Process Heap) and the reference is stored inside your stack so as to determine by some other Thread (called Finalizer thread) if the memory is still in use."

Now lets see how our compiler behaves when your own objects are created :

public class MyType
{
}
public struct MySType
{
}

/////////////////////////////////////

MyType t = new MyType();
Console.WriteLine(t);

MySType s = new MySType();
Console.WriteLine(s);

Console.ReadKey(true);

So here, I have created my own type, one as class MyType and another MySType while the former being a class directly inherits from System.Object while the later being a struct inherits from ValueType which in turn inherits from System.Object.

So both of them somehow inherits all the properties of System.Object. Then why this discrimination between the two ?

Yes, actually if you think internally, the language implementers actually implemented this for us. In IL, if you specify an object of ValueType it will indicate the object will be created directly inside your stack and will have a single reference to load the value from Stack. So if you look into the IL it looks like :

So if you see the locals, instead of creating int32 or object, it actually puts a class to hold object reference and valuetype to hold the actual value of the stack. valuetype are immutable object and will be de-referenced as soon as control returns out of scope.

The next line creates an object of MyType by calling its default constructor using newobj. Remember, newobj means it will return the reference to the memory it creates in Heap. Its IL construct, similar to box, which actually creates a newobj internally and gets you the reference to the value you pass on the valuetype. You can see the same happen for our struct too in L_0017 which takes up the already loaded variable and creates a newobj.

initobj on the other hand, initializes all the members to its default value and store in local stack. Yes ValueType does not require a default constructor.

So, if you think deep into it, according to specification the IL treats a class local as Reference Type which should be constructed using newobj and a valuetype local as a Stack object which is created using initobj. So we have covered one step deep to wipe out the abstraction that is provided by the language.

Hence, we can say, the C# compiler or any other compiler has the logic which indicates that if your type is somehow inherits from System.ValueType, treat it differently (use initobj to create it).

Our C# construct uses Struct to do the same. Hence if you declare a struct, it will write the IL in such a way that it is immutable and stack allocated which itself is high performance memory and does not require extra GC process to de-reference it.

Now as you are clear about it lets answer the question that I mention before :

Why do we say c# isnt pure Object Oriented because Value Types are not objects?

In fact, it must be clear it internally a pure object oriented and value type itself are inherited from System.Object, but C# writes the IL for ValueType specially such that the memory it allocates does not involve an extra load to Heap to reference and de-reference objects much quicker. So if your compiler / or Language does not use the facility that is exposed to IL which allow you to create a stack immutable object, it could have allocated all valuetypes into heap. Its an added facility that the language provides to us.
Value Types gets created over stack because to save space over heap or may be for performance right because heap creation takes time.

ValueType are specially treated objects that are created directly into stack for high performance, as Stack is created on ThreadLocal storage which is limited to 1MB, but can allocate and deallocate very fact because it just moves the Pointer back and forth. Hence it saves processor cycles.

Actually we dont require to save space on heap, as Heap size is limited to the process not something to the Thread itself. Hence Heap size can be increased too at times. We use stack over heap because it is high performance and cleared more easily than the later.
Why are Value Types struct and not class if they both are objects. To avoid complexity for simple types?

Well, I think the question is already answered. But yes, value types are syntactically defined using struct in C#, but theoritically if you want, you can possibly build your own language which writes IL for types which are marked somehow as valueType probably implementing your class from System.ValueType to ensure it writes initobj rather than newobj for those classes.

But as we already know struct from C, Language team used this construct to define a valuetype. Yes to make programming simplistic.
Why we have to do boxing and unboxing if valuetypes are objects too, or just to copy from stack to heap and back on?

By saying object if you are talking about System.Object type, then yes, ValueTypes are actually a special objects that are created on local stack and referenced and de-referenced quickly. But if you are talking about object in terms of storage, valueTypes are not a normal object, but a special one that are immutable. Hence it needs to be boxed, I mean stored to Heap when it needs to be used as reference type. And Unbox when the object needs to be reallocated to stack.

I hope you enjoyed this post.

By the way, It is not always true that every ValueType is allocated in Stack. You can go for the Second part of the Series from here. On the other hand if you are eager to know more about internals of C# please read my posts on internals of C# language constructs.

Please put your feedback as comments.

Thank you for reading.

Rethinking my Session on TechEd on Road

2011-07-03T23:27:00.000+05:30

Hi Folks,

Its been a great time together on TechEd on Road event here in Kolkata. I can recollect the fun we had out of the sessions with Pinal Dave, nice to find you here Pinal and with Bijoy Singhal on Windows Phone 7. I would also like to thank Dhanajay Kumar for coming all the way from Pune only for this session, and also for giving a wonderful session to us.

Lets now talk about my session on ".NET Fundamentals that every developers should Know". In this post I will share all the resources and source codes to make your easy way round to understand everything that you didnt understand in the session, of course if any... :)

The Presentation

Net 4 Features that Every developer should know

View more presentations from Abhishek Sur.

The Resources

The Session is actually divided into three sections.

Language Enhancements (mainly C#)
DateTypes included in .NET 4.0
Framework Enhancements

Lets discuss each of them in brief :

1. Language Enhancements :

Named and Optional Parameters

One of the First enhancements that were made in the .NET framework 4.0 is Named and Optional Parameters. You can now use Optional Parameters which you can omit during its call so that the default value that you specify in the argument will automatically be initialized with. Please note, that the default value of the parameters must be a constant, as IL manipulates the initialization.

Links :
Features of .NET 4.0

Dynamic Dispatch

The new dynamic keyword introduced in .NET framework 4.0 allows you to defer the compiler type checking at runtime. You can invoke any method on an object of it and the compiler will ignore the calls strictly yet the type checking will be done during Runtime.

The DLR implementation can also be moved further using IDynamicObject interface that lets you build a truly dynamic object at runtime.

Links :
Features of .NET 4.0
Dynamic Behaviour on Objects at Runtime With Custom ExpandoObject

Covariance & Contra-Variance

Generic Type parameters does not follow variance before .NET 4.0. That means the basic rules of OOPS inheritence does not corresponds in case of collection. .NET 4.0 adds a new feature on Co-variance and Contra-variance which allows you to make typesafe conversion of Generic types to its more derived type.

Links :
Working with Co-Variance and ContraVariance
Features of .NET 4.0

2. Data Types included in .NET 4.0

In this section I have discussed some of the data types that are new to .NET framework 4.0. The data types that I have covered are BigInteger, ComplexNumber, Tuple, Lazy, SortedSet.

Links :
Working with BigInteger
Working with Complex Number
Working with SortedSet
Lazy initialization to Defer object creation
Working with Tuple

3. Framework Enhancements

Managed Extensibility Framework

Managed extensibility framework deals with Extensibility that is most often required in mordern days. In this section I have created an application that supports extensibility and also allows pluggable application.

Links :
Managed Extensibility Framework - A Look
MEF - Extensibility

Parallel Extensions to .NET

.NET now wraps around the Threading model into a new framework of classes that allows you to handle Threads more easily than before. The set of classes can use ThreadPool automatically inside it and also can be spread in multi - core platforms.

Links :
Parallel Extension to .NET

Code - Contract in .NET

Code contract is another set of classes that allows you to handle your validation easily. I am sorry that I cannot cover this section in the Session, but the article would definitely help you. I have also added one application with the source codes.

Links :

Code Contract and its Internals

Source Codes Demonstated in the Session :

I hope you all like my session.

Please write your feedback too.

Thanks, Happy Coding.

Managed Extensibility Framework - A Look

2011-07-03T22:27:00.001+05:30

Hi guys,

If you are really new to .NET framework 4.0, this is going to be a quickstart guide to a new framework for extensibility which every developers should know. In this post, I will give you a brief introduction to what Managed Extensibility Framework is all about and also create a sample application on the same.

Note: This is the basic stripped version of MEF, if you are looking for something more advanced, stay tune with my blog; its about to follow.

Why Managed Extensibility Framework?

You can say MEF is a framework that is built on top of Reflection API, that addresses one special kind of requirement that most of the current developers are in. Modularizing an application is one of the biggest concern for any software giant. Everyone, like me, look for some sort of plugin based modularization for their respective application and ultimately end up doing in their own way like what I did before, which ultimately does not solve the problem as someone else might end up doing the same thing little differently and eventually "my plugins cannot go into your application" kind of situation. Hence we need some sort of standardization to address this situation such that every plugin based application can work together. MEF addresses this situation by giving you a sleek way of defining your modules as plugins and your application as a Standard host of any plugins.

Lets start this using Code-First approach.

To start with MEF you need .NET framework 4.0 and you need to add an assembly "System.ComponentModel.Composition.dll" to your project. Once you are done with this, lets start writing some simple code here and explain the concept as we go.

Create a console application to host your components. Add a Class Library to the project and add an interface to it.

public interface IProcessor
{
    TimeSpan ExecutionTimeSpan { get; set; }
        
    long Process();
        
    string Message { get; set; }

    Action<string> InvertMe { get; set; }
}

The interface IProcessor is just a contract that both plugin and my application will follow. Even though you can create your application without even having an interface, I will talk about it later, but for the time being, I have made a strict contract between the pluggable modules and the application that hosts the plugins. The interface IProcessor has few methods in it which we need to implement somewhere. But where? Lets see.

Add a Class Library to the Solution and name it as SerialProcessor. This would add a new class to the project. Lets rename that to SerialProcess. Add reference to System.ComponentModel.Composition.dll to the project and also a reference to the Interface library. Once you are done, lets add this code :

[Export(typeof(IProcessor))]
public class SerialProcess : IProcessor
{
#region IProcessor Members

public TimeSpan ExecutionTimeSpan
{
get;
set;
}

public long Process()
{
DateTime startTime = DateTime.Now;

long j, rem, result = 0;
for (long i = 2; i <= 5000; i++)
{
for (j = 2; j < i; j++)
{
rem = i % j;
if (rem == 0)
break;
}

if (this.InvertMe != null)
this.InvertMe(string.Format("Step [{0}, {1}]", i, j));

if (i == j)
result = i;
}

this.ExecutionTimeSpan = DateTime.Now.Subtract(startTime);

this.Message = string.Format("Finished processing in {0} ticks", this.ExecutionTimeSpan.Ticks);
return result;
}

public string Message
{
get;
set;
}

public Action<string> InvertMe
{
get;
set;
}

#endregion
}

For time being do not concentrate on the logic that is written inside the code, just concentrate on the attribute that I specified on the class. ExportAttribute is a special attribute that comes with MEF which is used to mark a class to be used as Plugin to another application that imports it. Or in other words, you can say, all the code that you want to expose to the application that hosts the plugins should be marked with Export attribute.

Hence you can say, the Types/ Methods/ Properties etc once marked as Export will only be exposed to the Host which consumes the Plugins. I think you got the point clear now. Isnt it.

You can also pass few other MetaData imformations on the Type using [ExportMetadata("Foo", "Name")] attribute that can be associated with the type as well. Say for instance,

That means you can access the string value Message as KeyValuePair from the Imported Type of IProcessor. As the Value is actually an object type and also it supports Multiple, hence you can send as many information as you want with your type.

Once you are done lets add a new class to the Main Console Application to consume the exported IProcessor class. Lets see how the class looks like :

public class AssemblyProcessor
    {
        [Import(typeof(IProcessor)]
        public IProcessor CurrentProcessor { get; set; }

    }

Once you are done importing the IProcessor interface to the main application you need to determine how the plugin should be attached to the application. For simplicity lets Load the assembly from a certain location and pass it using Assembly.LoadFrom.

Assembly asm = Assembly.LoadFrom("SerialProcessor.dll");

var catalog = new AssemblyCatalog(asm);
            

var processor = new AssemblyProcessor();
var container = new CompositionContainer(catalog);

container.ComposeParts(processor);

if (processor.CurrentProcessor != null)
{
     IProcessor currentProcessor = processor.CurrentProcessor;
     currentProcessor.Process();

}

So here few things that you need to understand. First of all, the First line in the code actually Loads the a Dll from file system to an assembly using Reflection Api. Once the assembly is successfully loaded in an assembly instance, we need to create an object of AssemblyCatalog. The assemblyCatalog class enumerates all the types, methods, fields that has Export Attribute in it and create a collection of ComposableParts. Oh wait, wait.. Lets define ComposablePart first.

ComposablePart

A ComposablePart is a composable unit in MEF. That means it holds all the information regarding either Export Unit (in our case IProcessor) or an Import Unit (nothing in our case, as our plugin does not include any Import Attribute). Hence each catalog exposes a property Parts which holds a collection of ExportDefination and ImportDefination where ExportDefination holds each Exports and ImportDefinations holds each Import.

If you loop through all the Parts of a catalog using the code below you can get all the information regarding the Exported type IProcessor.

foreach (var part in catalog.Parts)
{
    foreach (var exp in part.ExportDefinitions)
    {
        Console.WriteLine("Export Contract {0}", exp.ContractName);

        //Write MetaData 
        foreach (var metadata in exp.Metadata)
            Console.WriteLine("Metadata {0} for Part : {1} is {2}", metadata.Key, exp.ContractName, metadata.Value);
    }
}

The code will list all the Contracts defined within the assembly which is loaded in the catalog. The MetaData will list all the MetaData informations added to the Type using ExportMetaDataAttribute (which in our case is a message Serial Processor).

Once the Exports are loaded, its time to Map each Export defined in the dll (SerialProcessor.dll) with the corresponding Reference in the application which is defined within the class AssemblyProcessor. To do this we need a CompositionContainer.

var processor = new AssemblyProcessor();
var container = new CompositionContainer(catalog);
container.ComposeParts(processor);

if (processor.CurrentProcessor != null)
{
       IProcessor currentProcessor = processor.CurrentProcessor;
       currentProcessor.Process();

}

So here we first create an Instance of AssemblyProcessor that I have defined in the assembly and then create an instance of CompositionContainer and pass our Catalog into it.

The CompositionContainer gets Exports from the catalog and ultimately maps with Imports when ComposeParts extension method is called.

Hence when we call ComposeParts and pass a type (in our case AssemblyProcessor) it will find all the Import defined on the type and maps the Export with its respective Import.

What if I have more than one Type implements IProcessor with Export attribute ?

Interesting question. Yes in such a situation, you need to use ImportMany rather than Import. Lets see how to deal with such scenario.

If you have more than one Type that matches the criteria, you need to use ImportMany attribute to load it into an IEnumerable. Now the CurrentProcessor will hold a collection of types that implements IProcessor and also has an Export Attribute.

MEF is dynamically composed, How ?

Managed Extensibility Framework actually takes help of Reflection API to load Types dynamically during runtime. It exposes and maps Export with Import directly during runtime and invokes each method at runtime. So once the appropriate types are loaded you can use it normally in your code.

So our application is now ready. Lets try it now and it works.

So parallel will be invoked in First occation and then Serial. It also lists the Threads in Threadpool. You can find the complete application from here :

Please try the application.
I hope this gives you a brief idea on why we need MEF. Looking for more advanced thing? Stay tune, its coming very soon. Follow me to get updates.

Thanks for reading.
Happy Programming

Some facts about Null in .NET

2011-06-25T18:23:00.001+05:30

As I am tweeting around the facts on Nulls for last couple of days, I thought of writing a blog on that as many of you have already requested me on this regard. This post is basically dealing with Nulls and will go through only with basic C# stuffs, so for geeks, it is not recommended and you might end up knowing a little or almost nothing. So if you just here for time pass, then I refer to read on.

Considering the fact Nulls appear on any objects, we have mainly two categories of programmable storage in .NET.

Nullables (generally mutable with exceptions like strings)
Value Types / struct (generally immutable)

Nullables are types that either user defined or in framework in which one of its value can be null. .NET treats null specially. Say for instance :

class Program
    {
        static void Main(string[] args)
        {
            X xobj = null;
            Y yobj = null;

           
        }
    }

Here both xobj and yobj holds null, but you cannot equate xobj == yobj. It is illegal.

Another important fact is Unassigned local values are not treated as null. .NET compiler throws exception when an unassigned variable is used. But if you declare the member of a class unassigned, it will automatically be assigned to null. Hence :

static void Main(string[] args)
        {
            X xobj;
            Y yobj = null;

            xobj = xobj ?? new X();


        }

Throws exception while :

public class X
    {
        Y yobj;

        public X()
        {
            yobj = yobj ?? new Y();
        }
    }
    public class Y
    {
    }

And it does not throw any exception.

Note : If you don’t remember ?? in the above code, then it’s the new Null Coalesce Operator which assigns the value on the right when value on the left is null.

Another important thing that comes with Nulls are Nullable value types. We can use Nullable where T is a struct easily to interface a valuetypes to take nulls.

int x = 0;
int? x = null;

Where int? is a short form for Nullable. Cool huh. Nullable object contains two properties, HasValue which indicates whether the object is assigned to any value. It returns false when the value is null, and Value which holds the value. The value returns default(int) when the HasValue is false.

NullReferenceException

Yes, while working with .NET one of the message that you see the most in your code is “Object reference is not set to an instance of object”. Well, its actually a message coming from NullReferenceException, and you can do nothing with it. When your code encounters a NullReferenceException it does not hold the call stack or even the actual object that generates the exception, so there is nothing we can do with it.

Say for instance,

X x1= null;
Console.WriteLine(x1.ToString());

Here ToString cannot be evaluated on Nulls, and hence throws NullReferenceException. So be careful to check your code full proof so that the value x1 cannot be null.

Null follows object hierarchy:

Well, it is interesting that Nulls actually follows object hierarchy. That means the object of a class which is the most derived is taken to be more nullable than its base. Say for instance,

class Program
    {

        static void Main(string[] args)
        {
            MyClass mclass = new MyClass();
            mclass.Call(null);

            Console.Read();
        }

        
    }

    public class MyClass
    {
        public void Call(X x1)
        {
            Console.WriteLine("Called X1");
        }
        public void Call(Y y1)
        {
            Console.WriteLine("Called Y1");
        }
        public void Call(object x)
        {
            Console.WriteLine("Called object");
        }
    }

    public class X
    {

    }
    public class Y : X
    {

    }

The output will be “Called Y1” as you can see Y is the most derived class.

Hence you can say, nulls are more prone to more nullables. If you have not defined the overload with Y, it would have called X, and finally it would have taken object.

Note: If you overload the call method with a method which takes an object Z which does not belong to family of X, the call to the method Call would produce a compiler error saying about ambiguity.

.NET nulls are very vital. Programmers generally try to avoid it but at times, it is the most important value for an object. Any object derived from the family ValueType is not nullable, but other than that most of the others are nullable.

That’s all folks.

Happy Coding.

Concept Overide vs Method Hiding in terms of C#

2011-06-25T01:06:00.001+05:30

Overriding is one of the most interesting topic that many software professionals are dealing with quite regularly. Most of the applications we write in .NET or other languages somehow uses overriding. While you write your class, one of the most important thing that you need to consider is overriding ToString() to ensure that your class does not produce the “Name of the class” rather you produce something useful on your context. Method hiding is another concept similar to Overriding but is actually different in many respect. But I saw many people does have a little confusion among these two concepts and does not know when to use what. Here is some sample which would help you deal with these concepts easy.

Overriding

Overriding means redefining an existing method that comes inherited from parent class. Say for instance, you have defined a class Animal. Animal can move and eat. So let’s define the class :

public class Animal
    {
        public virtual void Walk()
        {
            Console.WriteLine("Animal is now Walking");
        }
        public void Eat()
        {
            Console.WriteLine("Animal eats for living.");
        }
    }

So this is quite a simple class that provides two methods. The first one is Walk which prints a message, and another is Eat, which again prints another message. Now notice, I have made the Walk method of Animal Virtual. Virtual means, the method will be bound at runtime, hence no compile time binding will be produced and runtime object will take over compile time bindings.

Now let’s define another class Dog which is derived from Animal.

public class Dog : Animal
    {
        public void Bite()
        {
            Console.WriteLine("Dogs can bite");
        }

        public override void Walk()
        {
            Console.WriteLine("Dog walks in four legs");
            base.Walk();
        }
    }

So here the class Dog actually overrides the method Walk and writes another message. base keyword is used to point to base class method.

Now let’s try the two classes

So basically calling d.Walk will actually call the method that I have defined for Dog class. You can see when I create the object of Dog, it can also call the Walk method defined in Animal class which is inherited to it using base keyword. Hence you can say both method co-exists side by side.

Now let’s change the call a little :

So here I just changed the Reference type to Animal from Dog. But it seems to have no effect on output. It can still call it. So :

Override for virtual method determine its link at runtime based on actual object rather than the Type it specifies. (as here reference of Animal actually calls Walk of Dog as we pass object of Dog to it)
For every object both set of inherited members and its own overridden methods co-exist, where the base method can be accessed using base keyword.
Override keyword is used to override a virtual method.

Method Hiding

Method Hiding is a concept new to C# which hides the inherited member of a class with a new one. In case of Method hiding the runtime linking does not occur, hence compile time Links are important while both the method co-exists in the object.

Let’s try to override the method Eat in Dog.

public class Dog : Animal
    {
        public void Bite()
        {
            Console.WriteLine("Dogs can bite");
        }

        public override void Walk()
        {
            Console.WriteLine("Dog walks in four legs");
            base.Walk();
        }

        public new void Eat()
        {
            Console.WriteLine("Dog eats meat");
            base.Eat();
        }
    }

Here the Eat method coming from base class Animal is hidden using a new keyword. This is called method Hiding. Notice, you can still access Eat of Animal using “base” keyword. Then what is the difference? Let’s try:

So if I call Eat method from Dog object, it will call the Method Eat from class Dog which in turn can call the Animal. Hence the output in this is same as override.

On the other hand,

Here you can see, the Runtime object cannot call the method Eat of Dog, even though we pass the object of Dog on Reference Animal. Hence the Compile time binding cannot be overridden in case of Method Hiding.

In terms of IL

Yes, IL is no different for the two cases. Callvirt is actually used to produce a late bound call to a method, but as I said Method hiding cannot override the Compile time bindings, it will call Eat method of Animal that is written during compilation rather than override, which calls Walk appropriately with because of virtual method.

I hope this post comes handy.

Thanks for reading.

Working With Prism 4.0 (Hello World Sample with MVVM)

2011-06-05T22:30:00.001+05:30

Modularity is one of the primary concern when working with a big projects. Most of us think of how we can implement our application that could be reusable across more than one applications. Patterns and Practices Team puts forward the notion of modularity with the help of Unity and Prism which most importantly focus on WPF and Silverlight applications. Being a WPF developer, it would be nice to take this apart and explain you a bit of how you can implement your application using Prism.

Before you begin, I must tell you, this is the most basic article that guides you step by step how you can write your first Prism based application and what are the advantages of building such kind of application. I will take this further in my next posts to make more concrete samples. So if you know the basics of how you can work with Prism, I would recommend you to read my next posts.

Also I assume you have some knowledge of Unity, WPF and MVVM to get you through with Prism.

Where do I find Prism?

Prism is a framework introduced by Patterns and Practices Team which is available from here. After you install your bits, you will get a folder named Prism on your local drive. After you are done, lets start coding.

Starting Our Application

Lets create a WPF Application now using Prism. To do that,

Start Visual Studio and Create WPF Application.
A MainWindow.xaml will be automatically created for you. Add some assemblies in the project you have just created.
You will find these dlls inside Bin directory under Prism. Remember to choose Desktop for WPF application.
Once all the dlls successfully added we need to create a Shell first.

What is a Shell ?

As Prism supports resolution of modules, you need a container where all the modules would appear. You can think of a Shell as your Window where all your UserControls can appear. Lets say I use MainWindow.xaml for our Shell.

But that is not all, to make your window act like a UnityContainer, you need to change the design like below :

<Window x:Class="SimplePrism.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:cal="http://www.codeplex.com/prism"
        Title="MainWindow" Height="350" Width="525">
    <ItemsControl Name="MainRegion" cal:RegionManager.RegionName="MainRegion"/>
</Window>

You need to get rid of the Grid and specify an ItemsControl and specify the RegionName for the RegionManager which we will use later.

Note : You can customize this window according to your wish, and the design will be common to all the modules. ItemsControl will act as a Container to the Shell.

Registering Types

After you have defined your Shell, you need to register some of the interfaces that will be called automatically from the container. Rather than doing this, we will use some existing Bootstraper that will do these for us. The Bootstrapper actually runs the Bootstrapping sequence to Resolve the classes needed to be configured before working with UnityContainer. The interfaces that it needs to Register are IServiceLocator, IModuleManager, IRegionManager, IModuleInitializer, IEventAggregator etc. I will discuss them sometime later.

As we are going to use Unity for modularity, we use UnityBootstrapper abstract class.

Create a class in your project and derive it from UnityBootstrapper. We need to override the abstract method CreateShell at least to work with it. Lets do it now :

public class MyOwnBootStraper : UnityBootstrapper
{
    protected override DependencyObject CreateShell()
    {
        return this.Container.Resolve<MainWindow>();
    }

    protected override void InitializeShell()
    {
        base.InitializeShell();

        App.Current.MainWindow = (Window)this.Shell;
        App.Current.MainWindow.Show();
    }

    protected override void ConfigureModuleCatalog()
    {
        base.ConfigureModuleCatalog();

        ModuleCatalog moduleCatalog = (ModuleCatalog)this.ModuleCatalog;
        //ToDo : Add modules that you need. You can also use Configuration for this.
    }
}

You can see we pass MainWindow to resolve the Shell inside CreateShell where the MainWindow is the name of the Window in the project that acts as a container for the Unity. Other than that, we also need to ConfigureModuleCatalog. Here I didn't add any ModuleCatalog, and will do as we go on add a new Module for the application. And Finally the InitializeShell is used to Show the Window that is referred to the Shell (viz, MainWindow).

Finally from App.xaml we need to Run the Bootstrapper.

public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);
            MyOwnBootStraper bootstrapper = new MyOwnBootStraper();
            bootstrapper.Run();
        }
    }

Hmm. Looks like we are done with the application. Lets try to run it. You will see the blank window appear on the screen.

Creating the Module

Now as you are done with the container, lets try to add a module which would be loaded into the Window. To do this, lets add a new project to the solution. You can add a Class Library if you wish, but in that case you need to add dlls that you need for Presentation layers. For the time being I am choosing another WPF application for the module.

We call it SimpleModule. For this project we need to add Microsoft.Practices.Prism.dll.

Delete the App.Xaml and MainWindow.Xaml and add a new UserControl for your application.

Before we start designing the module, lets add a ViewModel for the application. For that we use a ViewModelBase class which derives INotifyPropertyChanged event used to update the UI. The class is named as SimpleViewModel which looks like :

namespace SimpleModule.ViewModel
{
    public class SimpleViewModel : ViewModelBase
    {
        private string _message;
        public string Message
        {
            get { return this._message; }
            set
            {
                this.OnPropertyChanging("Message");
                this._message = value;
                this.OnPropertyChanging("Message"); //ensures the UI gets updated.
            }
        }

        private ICommand _SendToViewModel;
        public ICommand SendToViewModel
        {
            get
            {
                this._SendToViewModel = this._SendToViewModel ?? new DelegateCommand(this.OnSendToViewModel);
                return this._SendToViewModel;
            }
        }

        /// <summary>
        /// Called when Button SendToViewModel is clicked
        /// </summary>
        private void OnSendToViewModel()
        {
            string message = this.Message;

            if (!string.IsNullOrWhiteSpace(message))
            {
                MessageBox.Show("You passed the message " + message, "Welcome!", MessageBoxButton.OK);
                this.Message = string.Empty;
            }
        }
    }
}

The class is very basic. It has one Property called Message which takes a Message from the UI. As mentioned, for any property that you use from UI you need to call INotifyPropertyChanged event to update the UI. The ICommand interface actually fired when the Button on the page is clicked. hence it shows up a messagebox and clears the text.

Let me put the ViewModelBase as well here to make it more clear :

public class ViewModelBase : INotifyPropertyChanged, INotifyPropertyChanging
    {

        public ViewModelBase()
        {
            
        }



        //Here you need to have your DataLayer Manager object or BizLogic to access database

        //private DataManager _manager;
        //public DataManager Manager
        //{
        //    get
        //    {
        //        this._manager = this._manager ?? new DataManager();
        //        return this._manager; 
        //    }
        //}

        #region INotifyPropertyChanged Members

        private void OnPropertyChanged(string propertyName)
        {
            if(this.PropertyChanged != null)
                this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName);
        }
        public event PropertyChangedEventHandler PropertyChanged;

        #endregion

        #region INotifyPropertyChanging Members

        public void OnPropertyChanging(string propertyName)
        {
            if(this.PropertyChanging != null)
                this.PropertyChanging(this, new PropertyChangingEventArgs(propertyName);
        }

        public event PropertyChangingEventHandler PropertyChanging;

        #endregion
    }

Even though INotifyPropertyChanging is not actually needed in this scenario, but it is better to use it together.

Note : From your ViewModelBase you should connect to Database Layer or BizLogic Layer if you have any so that data is available here. We have also added a class DelegateCommand which acts as a CommandPattern derived from ICommand interface for Button click. It just fires the Action that we pass.

Once you are done with the ViewModels, lets add some xaml for our UserControl so that it could be loaded on the Container we have created.

<UserControl x:Class="SimpleModuleLibrary.SampleView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             xmlns:model="clr-namespace:SimpleModuleLibrary.ViewModel"
             mc:Ignorable="d">
    <UserControl.Resources>
        <model:SimpleViewModel x:Key="SimpleModel" />
    </UserControl.Resources>
    <Grid DataContext="{StaticResource SimpleModel}">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition />
            <ColumnDefinition />
        </Grid.ColumnDefinitions>

        <TextBlock Text="Write anything : " />
        <TextBox Text="{Binding Message, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" 
                 Grid.Row="0" 
                 Grid.Column="1"/>

        <Button Grid.Row="1" Grid.ColumnSpan="2" 
                Content="Send Your Message"
                Command="{Binding SendToViewModel}"></Button>
    </Grid>
</UserControl>

Hmm, So basically I create one textbox and one Button, which invokes the respective PropertyChanged on the ViewModel.

Now after you have created the View in the Library, you need to register the View as Module. You should do it once for each Module (which may contain more than one view in turn).

public class SimpleModule : IModule
{
    private readonly IRegionViewRegistry regionViewRegistry;

    public SimpleModule(IRegionViewRegistry registry)
    {
        this.regionViewRegistry = registry;   
    }

    public void Initialize()
    {

        //We need to register our Module in MainRegion.
        regionViewRegistry.RegisterViewWithRegion("MainRegion", typeof(SampleView));
    }
}

The IModule interface will tell the application to Register the View as a Module which could be loaded into MainRegion. If you have multiple Regions available, you can do it from here.

Hey, I think the application is ready to be deployed. One thing that remains, is to add the Module in the ModuleCatalog. Lets do it now :

protected override void ConfigureModuleCatalog()
{
    base.ConfigureModuleCatalog();

    ModuleCatalog moduleCatalog = (ModuleCatalog)this.ModuleCatalog;
    //ToDo : Add modules that you need. You can also use Configuration for this.

    moduleCatalog.AddModule(typeof(SimpleModuleLibrary.SimpleModule));
}

Basically the ModuleCatalog will hold all the modules that you need to register for the whole application.

Please Note : Before you run the application change the Build Action of XAML to Page from ApplicationDefination.

Running the App :

So we have finished building our first application. Run the application you will see something like this :

The MessageBox appears on the screen which shows the message you pass through the TextBox.

Please Note : Rather than Registering the Modules directly from the Bootstrapper, you can also use Configuration to do the same. We will try to cover it on my next post.

You can Download Sample Code from here .

Read more about Prism.

I am sorry for not getting too deep in this post, you will find them in some of my next posts.

Thank you for reading.