Nauman Leghari's Blog

Blog about technology, media and other interesting tidbits

  • SequenceViz is going Pro

    This is one of the things on my mind for quite some time. As with most other software developers, I wanted to start a microISV to experience the whole product development cycle. To get an idea wasn't as important as the execution so I decided to take one of my open source project to begin with. And that project is SequenceViz.

    SequenceViz is my latest open source project which was very interesting to work on and received a lot of community attention. According to the codeplex stats, the number of downloads are +25000 and that didn't include the downloads before I put it on codeplex. Although this number is not the reason behind selecting SequenceViz.

    The work on SequenceViz Pro is already started and if everything goes according to the plan, I'll be releasing the beta of SequenceViz Pro soon. This blog will become the primary source for any updates on that project along with my twitter feed.

    So What'll happen to SequenceViz @ Codeplex:
    The plan is to leave the open source version as it is and I'll not be taking it any further. I'll also remain as project coordinate so If you're willing to improve the open source version then please contact me.


  • GmailSync on codeplex

    By far the most popular tool that I published is GmailSync which was also features on Lifehacker. But as I get busier in other projects, it is getting difficult to put more effort into it. Its been a while since I put the last update so I've decided to upload the sources hoping that I can find someone to lead on this.

    You can download the binaries and check out the sources from the following url. As the source code is not the best I've written so I'm willing to work with anyone who is interested.


  • SequenceViz 0.9 :: WPF based Sequence diagram viewer

    Until now, SequenceViz uses the GnuPlot tool to generate the SVG file that is then rendered in the IE control embedded in the application. Although this worked to prove the concept but there were problems with rendering large diagrams and security issues in Vista. Now thanks to Meile Zetstra who provided the WPF implementation for the diagram viewer I have released a new version with this functionality.


    Hope you'll like this release and as always, provide your comments and suggestions to improve the application.


  • SequenceViz 0.7 :: Quick search

    I managed to spend some time on SequenceViz this weekend and added quick search functionality. Because the diagrams are not linkable so it is difficult to navigate between methods and types. One thing that could help now is to search for the type or method that you'd like to navigate to and it will take you to the first result.

    As always, please enter your comments or suggestions here.




  • CodeStore - Part 4 of n (Refactoring, Hudson CI Tool)

    Although there is not much in this project yet but I think there are few things that can be improved before moving ahead.


    Moving castle configuration from the App.config file to its own file:


    This is to remove the noise in the main application configuration file and it is as simple as extracting the castle configuration items into another file and passing that file name in the WindsorContainer constructor.



    Abstract IOC container:


    It is a good idea to abstract dependencies and therefore the reason of DI containers. But what about the DI container itself. One way to do this is to abstract it behind a separate class IOC.cs



    Moving the engine implementation into a separate namespace.



    Using Hudson as a Continuous Tool:


    I have used CC.NET before and I remember that it wasn't a smooth setup. So for this project, I've decided to try Hudson.


    Hudson is built on Java but it is extremely easy to setup and the .NET plugins for MsBuild, Nant, Nunit and support for running batch files makes it a viable alternate to CC.NET.  I found an excellent tutorial ( on setting up Hudson for .NET projects and believe me, it just works. 


    Once I completed the setup, the hudson dashboard looks like this. I've also checked in the configuration file that I used for this project.






    In this post, I've done some small refactoring on the project structure and then used Hudson as a CI tool. In the next post, I'll start putting in more functionality into the project.


  • CodeStore - Part 3 of n (Cecil, Moq)

    This is the third part of the series on building CodeStore. In this blog post, I'll finish off the first user story which was

    1)  As a customer, I want to query the Assembly data in the database so that I can get metrics about the assembly.


    The story is further decomposed into two tasks:


    a)   Read Assembly Data

    b)   Store Assembly Data in SQLite using Nhibernate.


    We start with completing the unit test for AssemblyDataRepository. If you remember in Part II  that I changed the Nhibernate integration to use Castle Nhibernate repository and therefore passing in the ISessionManager to the repository classes.


    So, to test AssemblyDataRepository I'm going to mock ISessionManager to test the behaviour of the method.  As this project is about learning so I've decided to use Moq ( as the mocking container. 


    Moq uses lambdas to set expectations which takes some practice to get used to. You can read more about Moq on Daniel Cazzulino blog (


    So we start with a test for adding assembly data using the repository.



    It uses the same test flow as other testing (mocking) frameworks.

    1. Setup data
    2. Setup mocks, expectations
    3. Run SUT
    4. Verity the expectations

    Once the test is passed, we can check off the second task of the story. I can write few more tests but let's not worry about that for now. The next thing to look into is actually parsing the assembly and extracting the required information from assembly metadata. To read IL, I'm going to use Cecil which can be downloaded from


    The initial model for code analysis engine looks like this. (Please note that the following diagram is the snapshot taken at the end of this blog post)


    I started with CodeAnalysisEngine whose job is to ask the CodeAssemblyLoader to load the assembly and then pass it to CodeAssemblyParser to do the actual information extraction.


    Testing CodeAnalysisEngine:



    The first two statements create the mock objects to use in the actual call. The next line sets the expectation to load the provided assembly file. The implementation of the SUT:



    In the next test, I added the assembly parser in the constructor which prompts a change in the first test to take in another argument.



    And the implementation now calls the Parse method on the assembly parser.



    The next step is to unit test the CodeAssemblyLoader. This class is responsible for loading the assembly file using Cecil, so the test expects a call to Cecil's AssemblyFactory.GetAssembly method. Unfortunately AssemblyFactory.GetAssembly is a static call which makes it impossible to test. If it is Ruby then I can easily mock it but that's another thing :).


    And, here is the implementation of CodeAssemblyLoader class



    Testing CodeAssemblyParser is also not easy because of the same AssemblyFactory issue so I'm going to load the actual assembly but mock the repository to expect the add method.



    Line no. 17 is loading the actual assembly. Then I mocked the repository and set it to the assembly parser. In the end, I set the expectation and call the method to verify.  The Parse method internally calls the AddAssemblyData method with the assembly definition.



    So the unit tests are passing, I still need to implement the dependency injection configuration to run the application.


    Setting up Castle configuration for dependency injection:


    There are two different dependencies which we need to resolve here. First, CodeAnalysisEngine depends on the CodeAssemblyLoader and CodeAssemblyParser which it takes in as constructor arguments.



    Second, to resolve the dependency in assembly parser for assembly data repository which is a property.



    After configuring the dependencies, I can run the application select the TestCases.dll file which we created in part II.



    To confirm if it works by opening the codestore.db file in the database browser.



    Source Code:



    So, this completes the first story which is about storing the information about the assembly into the database. I also looked into interaction based testing and used the Moq framework to implement mocks inside the tests. The assembly parsing is then implemented using Cecil.


    As always, your suggestions and comments are always welcome to improve the project.


  • CodeStore - Part 2 of n (SQLite, NHibernate)

     So, in the last post, I started creating a new application using TreeSurgeon and added Castle Windsor and log4net support. In this post, I'm going to describe how I added the Nhibernate support and the Castle Nhibernate facility.


    User Stories:

    Because CodeStore is about storing metrics about an Assembly therefore I'm going to start by storing the assembly information. Therefore the first user story is:


    1) As a customer, I want to query the Assembly data in the database so that I can get metrics about the assembly.


      After breaking the story into tasks, we have:

    a) Read Assembly Data

    b) Store Assembly Data in SQLite using Nhibernate.


    Although we can start with any task, but in this scenario I'll go with the second task which is about setting up Nhibernate to store data in the SQLite database.



    There are few things we need to download and setup before start coding.

  • Download SQLite ADO.NET Database Provider ( The good thing about this provider is that it embeds the sqlite database engine so you don't need any more dependencies.
  • Download SQLIte Database Browser to manage the database ( but you can also use the native sqlite engine to manage the database from console.
  • Download NHibernate.

    Once we have the required dependencies, we can start by creating a new datastore. SQLite Database Browser allows you to create a new database but you'll have to create a temporary table so that it can save it in the file.



    Then I added a new class AssemblyData in our Core.Domain namespace.



    Once all the fields are defined, I generated all the properties using Resharper (Alt+Ins)



    It seems that Resharper doesn't generate the auto properties so you'll have to fix it (Ctrl + Enter).



    Or you can just type the auto properties without any help which may be the quickest option :).


    The next step is to create the nhibernate mappings file. When editing the mapping file, it is much better to add the nhibernate mappings schema to get intellisense in the IDE.





    The complete mapping file looks like this. The build action should be set to embedded resource.


    <?xml version="1.0" encoding="utf-8" ?>

    <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"

                       assembly="CodeStore.Core" namespace="CodeStore.Core.Domain">

      <class name="AssemblyData">

        <id name="Id">

          <generator class="guid"/>


        <property name="Name"/>

        <property name="FullName"/>

        <property name="Version"/>

        <property name="EntryPoint"/>




    As we have the domain class and the corresponding mapping file, we can configure the application to use Nhibernate. For that, I created a separate hibernate.cfg.xml file in the Core application with the following contents. The properties are self-explanatory and you can always learn more by looking into the Nhibernate documentation.


    <?xml version="1.0" encoding="utf-8" ?>

    <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">


        <property name="connection.driver_class">NHibernate.Driver.SQLite20Driver</property>

        <property name="connection.connection_string">Data Source=E:\Code\CodeStore\data\codestore.db;Version=3;New=False;Compress=True;</property>

        <property name="dialect">NHibernate.Dialect.SQLiteDialect</property>

        <property name="query.substitutions">true=1;false=0</property>

        <property name="show_sql">true</property>




    To check whether the configuration is correct, I quickly wrote a test to generate the schema for the above domain model.



    public class HibernateTest



    public void CanExportSchema()


                var cfg = new Configuration();



                new SchemaExport(cfg).Execute(false, true, false, false);




    The above code will generate the AssemblyData table in the database with the defined fields.



    So this is one approach to design  (domain driven design) where we started with our domain model and then generate the database in the end. The other side of it is data driven design where you can start with the database and generate your domain from these entities. By using the database, you can also generate the plumbing code for domain model (i.e. Mapping files and Domain classes) using some generation tool like MyGeneration or CodeSmith.


    Now, using the Repository pattern, I'm going to create a repository to save assembly data into the database.



    Although not TDD, but writing a test now.



    If the code looks familiar to you then you must have been to the excellent tutorial on this website.


    Currently we are using plain vanilla Nhibernate through the NHibernateHelper which is not a bad thing but there is Castle NHibernate facility that we can utilise and abstract the Nhibernate plumbing. To do so, there are two different types of integration styles (defined here) I'm using the second approach which looks more straight forward.


    The first thing is the change in configuration file.  The hibernate configuration is currently defined in a separate hibernate.cfg.xml file which I'm going to move into the app.config file inside the existing castle/facilities section.



    The second thing is to change the repository class to inject ISessionManager (link) in the constructor.



    And then you can use the data repository as:



    Source Code: 



    In this blog post, we started with creating a database and the domain model for storing AssemblyData. In the next post, we are going to use mocks to test the repository.


    As always, comments and suggestions are most welcome to improve the project.


  • CodeStore - Part 1 of n (TreeSurgeon, Castle Windsor, Log4net)

      What is CodeStore?

      The idea behind CodeStore is to extract information about .NET assembly and store it in a database. One we have the data, we should be able to run standard SQL queries on the data store. Although, I'm planning to develop a WPF project to show some visualisation but let's see how it'll go.


      So why CodeStore?

      I needed a pet project as it's been some time from my last one. And I get more into Ruby and Java, this gives me an excuse to keep up my .NET skills. This is also an experiment to maintain a running project diary on this blog.


      Tools to use:

      Nhibernate: data access

      Castle Windsor: application plumbing
      Log4Net: logging (link)

      ... And many more



      I started with setting up our development environment and one thing that proved very useful to me in the past is TreeSurgeon (  TreeSurgeon is an excellent tool to generate your development tree. It definitely saved a lot of time at the start of the project.



      Once the solution is generated, we can quickly check if the build is working.



      Code check-in:

      Then I created a project on google project hosting which is available at



      I used TortoiseSVN ( to import the project and AnkhSVN ( for Visual Studio integration. 


      To ignore certain files, I've also setup the following pattern into TortoiseSVN global ignore pattern. (TortoiseSVN->Settings->General)


      bin */bin obj */obj *.suo _ReSharper.* *.resharper *.resharper.user  *.user


      Writing code:

      Now we can start plugging in Castle Windsor and setup the configuration to inject a simple class. To do so, I added the three castle dependencies into the CodeStoreConsole project.



      And then using the following code inside Main() to resolve CodeAssemblyLoader.


      var container = new WindsorContainer(new XmlInterpreter())

      var assemblyLoader = container.Resolve<ILoader>("assemblyLoader");



      As you can see, it is using WindsorContainer  which is used to read the configuration file and resolve the components from the configuration. And the configuration looks like this.



            <component id="assemblyLoader" service="CodeStore.Core.ILoader, CodeStore.Core"

                      type="CodeStore.Core.CodeAssemblyLoader, CodeStore.Core">




      You can view the complete application configuration file here. Here is the output when the application is executed.



      At the moment, ILoader.Load() takes no argument, but we are going to change it so that it'll take in a file name. The target assembly is selected using the FileOpenDialog. This is a very common behaviour that I use so I think it would be better if I can put that in ReSharper Live Templates.



      Now, I can use it using the shortcut.



      After the code to open file, I added a new project in our solution which will be the target test case for the code analysis engine.

      Now, when the application is executed, we'll see that the file is successfully selected.



      At the moment, I'm using Console.Writeline to print the output which is not ideal so I'm going to replace it with log4net.


      One way to add log4net is to directly add it in your code (like I described in but there is also Castle Logging facility which makes it possible to abstract the logging engine (although you can also do this quite easily).


      One that topic, I found a very useful blog post by Casey Charlton about adding log4net with Castle factilities . In the end, I did it a little differently by extracting the Logger into its own class to avoid using properties in every method. The output generated in the log file is shown below.



      Source Code



      Although I don't have anything to show to the client but we covered starting a new project using TreeSurgeon and then adding support for Castle Windsor and log4net. In the next post, I'll look into Nhibernate to create the domain model and the database in SQLite.


      As always, any suggestions or comments are most welcome in order to improve the application.