Derik Whittaker

Sharing Code Analysis files between projects in Visual Studio 2010

Derik Whittaker — Wed, 10 Mar 2010 11:13:43 GMT

The ability to have static code analysis (aka run FXCop inside the IDE) is not something that is new to Visual Studio 2010. What is new is the simplicity in which you can share the exact same configuration across all of your projects at once.

Prior to VS2010 if you wanted to share your config it was not possible (from what I have ever seen). With VS2008 each .proj file contained a section in the file which laid out each rule that should/should not be turned on. If you wanted to share these what you needed to do was open up each .proj file in a text editor and copy/paste the rules. As you could image, copy and pasting this could get old real fast. In fact I would even argue that I may even prevent you from wanted to use the built in analysis all together.

Here comes Visual Studio 2010 to the rescue. In 2010 you can save your rules to a .ruleset file and you can import this same file into all your projects. No more need for copy/paste by hand.

Steps To Do This:

Step 1: Open up the Code Analysis tab in the project properties.

Step 2: In the drop down choose Browse

Step 3: Find your .ruleset file on disk

Step 4: Rinse and Repeat for all your other projects.

Now that having the ability to share your rule set across projects is painless you have NO excuse not to utilize this feature.

Till next time,

Providing Metadata to your MEF exports

Derik Whittaker — Sun, 07 Mar 2010 01:07:24 GMT

Many months ago I created a post on how to get started with MEF. Ever since then I have been meaning to get this post (and others) about about how to get up and running quickly with MEF.

In this post will demonstrate how to provide Metadata (custom values which can help provide context) information to your Exported item. Why should you care about Metedata? Below is a great reason from the MEF site on codeplex

Declaring Exports explained the basics of parts exporting services and values. In some cases it’s necessary to associate information with exports for a variety of reasons. Commonly it’s used to explain about the capabilities of an specific implementation of a common contract. This is useful to allow imports to either constraint the export that can satisfy it, or to import all available implementations at the time and check their capabilities in runtime before using the export.

Before we get rolling:

What I am going to show in this post is how to create a custom Export Attribute. It is possible to expose Meta via the build in ExportAttribute, but the built in mechanism has a few short comings:

Not discoverable
Not strongly typed
Compiler cannot validate the data content

Lets get rolling:

Pre-Step 1: Taking a look at the Class which we will mark as a Export

    public interface IPlugin
    {
        string PluginAction();
    }

    [Export(typeof(IPlugin))]
    public class DefaultPlugin : IPlugin 
    {
        public string PluginAction()
        {
            return "This is the default plugin";
        }
    }

Step 1: Defining the interface which will represent your

In order to create discoverable Metadata you will first want to create an interface which will represent your metadata. Below is my interface.

    public interface IPluginMetaData
    {
        string Name { get; }
        string Version { get; } 
    }

We will later use this interface when we define and use our custom Export Attribute. The main reason for creating this attribute is now the compiler has a hard wired way to know exactly what type of data is being exposed in your Metadaa

Step 2: Defining your custom ExportAttribute Attribute

Now that we created our interface to give us strong typing and discoverability we need to create a custom attribute which will allows the MEF engine to know we have Metadata to expose

    [MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
    public class PluginMetadataAttribute : ExportAttribute
    {
        public PluginMetadataAttribute( string name, string version)
            : base(typeof(IPluginMetaData))
        {
            Name = name;
            Version = version;
        }

        public string Name { get; set; }
        public string Version { get; set; }
    }

When looking at the code above there are 3 things to pay close attention to

You need to make a call into the base constructor of the ExportAttribute and provide it the type of your interface which defines your Metadata
You need to mark your attribute with the [MetadataAttribute] (which is part of MEF)
You need to mark the usage type of your attribute. I am not 100% why this is needed (Glenn, you out there with an answer???)

Step 3: Providing your Metdata to your Exported Class

    [Export(typeof(IPlugin))]
    [PluginMetadata("Default", "1.0.0.0")]
    public class DefaultPlugin : IPlugin 
    {
        public string PluginAction()
        {
            return "This is the default plugin";
        }
    }

The code above is the same as the code we saw in pre-step 1, but this time we have marked the class with our custom Metadata attribute. We have now officially provided our Metadata to our Export…. But how do we get this information out of MEF?

Step 4: Setting up your [ImportMany] to use the Metadata

If you are using an ImportMany (this should also work on an Import, but I have never tried) most likely you are pushing your Exports into a IList or IEnumerable. If this is the case, your changes are pretty minor. Below is what you need to do in order to have your Metadata loaded.

[ImportMany(typeof(IPlugin), AllowRecomposition = true)]
private IList<Lazy<IPlugin, IPluginMetaData>> _loadedIPlugins = new List<Lazy<IPlugin, IPluginMetaData>>();

If you have not seen the Lazy keyword, you are not alone. This is new to .Net 4 and this provides Lazy initialization support to the framework. (part of the System namespace). One key thing to understand here though is that the Lazy keyword out the box is only Lazy<T>, but the Lazy we are using is Lazy<T, M>. This extended version of Lazy lives in the MEF assemblies (System.ComponentModel.Composition) and will need to be referenced to use.

Step 5: Using the Metadata

Once you have the Export loaded into your container (which by the way does not need to change to have this work) you can access your container by selecting the .Metadata property on your instance of the export. The image below shows it in action.

As you can see, exposing and using Metadata via MEF is a snap.

Till next time,

Coding Concepts are Cross Language, because it is SQL does not means it should suck

Derik Whittaker — Mon, 01 Mar 2010 11:49:00 GMT

<Warning_Rant_AHead>

Today I was reviewing some commits by our team and I ran into one commit in general that first made me vomit a bit in my mouth, then get pissed as all hell that we committed code like this.

The code that was committed was a minor change to one of our ‘legacy’ (aka has no tests, written like a blind monkey coded it and god help the person who has to make changes to it) stored procs. Here are some details on the proc

Has about 2050 lines of code
Has about 141 variables
Has 6 Temp tables
Has > 50 update statements
Has ~13 delete statements
Has 8 Cursors

What makes me so mad is that this code when it was originally written was code reviewed by a senior developer on the team (I know this be cause like many other old school shops at that time we put our commit comments in the header of every file). I am going to bet the farm that had this been C# code and not SQL this would not have passed review. BUT for what ever reason SQL seems to be treated differently. When writing SQL many people throw best practices out the window, and I have NO clue why.

The one message I want to get across to anyone out there reading this is…. Code is Code and coding concepts are cross language. If while writing .net/java/ruby/etc code you follow practices like SRP, DRY, etc then why not follow those same principles when writing code in SQL (or any language for that fact)

</Warning_Rant_AHead>

Till next time

Issues Compiling VS2010 solutions (with web projects) from Nant

Derik Whittaker — Sat, 27 Feb 2010 14:40:00 GMT

Recently I upgraded a project of mine (the Dimecasts code base) to use VisualStudio 2010. In the process everything worked just fine from the IDE, but when I tried to compile it from the command line I would get the following errors:

Error MSB4064: The "Retries" parameter is not supported by the "Copy" task.
Error MSB4063: THe "Copy" task could be initialized with its input parameter.

After a bit a googling I came across a post which (and of course i cannot find it now) said that if you open up your .proj files and change the line that pointed to the v10.0 build of web applications and reset it back to 9.0 everything would compile. And this did work... BUT when you try to open that project up again in VS 2010 it will simply revert your changes... this is not a working solution.

Next I decided to switch my target framework in Nant from 3.5 to 4.0, but of course my nant.exe.config file does not support 4.0 yet. So after a bit more googling I found this post that gives details on how to add the missing values to the config file.

When I added the config information to my Nant.exe.config file things were better, but still not great. Now I was getting an error that said:

The "vendor" attribute does not exist, or has no value.

To resolve this I added the following under the <framework> node in my config
vendor="Microsoft"

After this I got another error.... This time it said that .Net Framework 4.0 was not installed. But I know this is not valid. After looking at the information for a few more seconds I realized the issue. The example config from the post above was build on an older version of the 4.0 framework (.20506) and I have .30128.

I changed all values in the nant.exe.config value that was v4.0.20506 to be v4.0.30128 and NOW I am able to compile.

So long story short, if you are getting the MSB4064 error you need to do the following:

Point nant to use the 4.0 framework tools
Follow this post and copy the framework section to your Nant.exe.config file
Add the missing 'vendor' attribute to the new framework section
Update the version in the new framework section to match the version you have on disk (check C:\Windows\Microsoft.NET\Framework for versions)
Compile again

Till next time,

Noisy code does not equal clean code

Derik Whittaker — Fri, 26 Feb 2010 01:16:00 GMT

Today I was having a conversation with one of the developers on my team (btw, this guy is going to be a rock star) and I made that statement to him that I thought we had some noisy code. The context around this conversation was with our usage of AutoMapper (which I love so DO NOT take this as a slight against the tool) and how by default using AutoMapper exposes too much noise and I do not like it.

When I made this statement to him he was not 100% sure what I meant, so in place of having a one-off conversation with him I thought I would try to explain my thoughts to the world (hey, that is the point of blogging after all, right).

When using AutoMapper to map objects from one type to another in your code you need to implement something like below:

var someMappedDto = Mapper.Map<SomeModel, SomeDto>(someModelInstance);

If you look at the code there is a bit of noise here in my opinion. So what do I mean by noise? I consider anything in my code that gets in my way or does not provide me direct feedback as noise.

In the line above I consider the following noise:

Mapper.Map – I do not like this because having Mapper.Map sprinkled all over my code base just means that my code has too much knowledge of the actually mapping library we use, this is noise. Hey, it was for this basic concept that the Common Service Locator was created to help prevent
Having to provide both the source type AND the destination type – The source type should be able to be derived from the source object instance (in cases where you do not want to use the mapper for some child type of the source type). I concede that you do need to provide the destination type other wise we would have no clue what you want in the end
Having to provide the source type instance in the constructor.

In order to reduce the noise, and make for cleaner code I would like to see something like

var someMappedDto = someModelInstance.Map<SomeDto>();

In my humble opinion the code above is cleaner and more concise. The code above has less noise to distract me from my coding efforts. In particular the code above addresses my 3 issues in regards to the noise

Now I am abstracting my mapping library of choice (AutoMapper) away into an extension method some place, thus giving me a clean abstraction layer
I do not need to provide the source data type as it can be inferred from the instance itself (yes, only in the case where the actual type being used is the type I want)
No need to provide the type to be mapped from (well not directly)

To me noise free code is clean, concise and easy to read.

Till next time,

Hey, NHibernate give me back my milliseconds

Derik Whittaker — Mon, 22 Feb 2010 22:47:00 GMT

Have you ever noticed that out of the box NHibernate’s DateTime type will truncate/ignore your milliseconds for DateTime fields? If you do not believe me check out this post. If you think about why it does this it will become clear, NHibernate runs against MANY databases and each one of them stores DateTime values slightly different. However all of them store basic YYYY-MM-DD : HH:MM:SS.

If you google how to resolve this issue you will find a few a post that suggests you create a custom User Type (IUserType). Although I am sure this will work, this just seems like such overkill for the problem.

What I was able to do was setup my mapping in FluentNHibernate as such

Map( x => x.MyField, "My_Field" ).CustomTypeIs("timestamp");

By adding the .CustomTypeIs attribute (i tried CustomSqlTypeIs but this did not work) NHibernate was able to save my DateTime property into a DateTime (not Timestamp or DateTime2) field with the milliseconds inplace.

Hope this helps,

Till next time,

Registration Error while Hosting WCF Services in a Windows Server

Derik Whittaker — Thu, 11 Feb 2010 19:46:00 GMT

Have you ever run into the following error while trying to host (start) a WCF service inside a Windows Service?

Starting WCF Services step has caused the following error HTTP could not register URL http://+:9997//Services/HashGenerationService/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).

If you have you are not along. Also, if you have clicked on the link for MS and felt like that was absolutely NO help, you still are not alone.

The simplest (maybe not the best) way to solve this issue is to configure your windows service (the one hosting your WCF services) to log on as ‘Local System Account’ as below.

Once you have done this try restarting your service and see if your wcf services start as expected.

Hope this helps.

Till next time,

Removing Generated code from NCover Reports

Derik Whittaker — Thu, 11 Feb 2010 13:12:00 GMT

If you are a user of NCover you know it has great power and that it can generate great results. But what do you do if you do not want to include certain items in your coverage report? In particular what do you do if you have generated code (say WCF Proxy code) which you do not want to skew your coverage numbers?

Simple, you exclude them right :)

If you are simply using the NCover Explorer this is easy, you can right click the namespace/type and say exclude. But what if you are using NCover from the command line? Well this is also simple.

All you need to do is use the excludeAttributes option for NCover.

The code above is what we use to generate our NCover reports, the important part is how we are using excludeAttributes. Now I know you are saying, wait you have a property being called, I want to see the ‘real’ value. Well it is below

excludeAttributes=”System.CodeDom.Compiler.GeneratedCodeAttribute”

Adding the code above will tell NCover to exclude any code with the above attribute (which should be good for WCF Proxies).

Till next time,

Help my DataContracts do not show up in my WCF Services

Derik Whittaker — Tue, 09 Feb 2010 11:28:00 GMT

The other day I refreshed one of our WCF services (right click the service and do a Update Service Reference) and all of a sudden I got a metric crap-ton of build errors. In each place I received the error it told me that the type was not found. At first I could not understand what was going on, in fact I was sure the compiler was playing tricks on me (cause we all the compiler has a devilish sense of humor) because how could it be possible that all of my types went missing.

Just to be sure I took a look at the generated code in the Reference.cs class and sure enough all my types were missing.

Now that I know the compiler is not just playing tricks on me it was time to find out what happened.

The first thing I did was to try recompiling the service and updating my references again, but as you could have guessed this did not solve my problem. Next I decided to try to create a duplicate reference to the service to see if maybe my original reference was screwed up, and as you may have guess the new reference also was missing my types (shocking I know). At this point I was a bit stumped, and did not know exactly what could have caused the issue. I next decided to take a look at the service configuration so I right clicked on the service and selected ‘Configure Service Reference’. When I did this the screen below appeared

After looking at this for a few minutes it dawned on me what had happened. The check box (one circled in red) was selected (and is by default) and someone on the team had added direct reference to the assembly which contained my Models that were provided via the web service. I decided to uncheck that check box and give that a whirl and sure enough my Models came pack. Now that I was back up and running, it was time to remove the direct reference from my project to the assembly which hosts my WCF service as there is no point in both referring to it locally as well as hitting it via a service.

Long story short, if you refresh your WCF reference and all your Data Contract Models disappear there are 2 things you need to look for.

Are you referencing the service assembly locally (if so why?)
Do you have the ‘reuse types’ check box selected in the WCF configuration screen?

If either (or both) of the above are set then you should have your solution.

Till next time,

MEF and decrypting LoaderExceptions

Derik Whittaker — Sun, 31 Jan 2010 14:51:02 GMT

Have you ever received the following exception while using MEF?

Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

if you have received this error did you scratch your head and wonder ‘what the F does this mean’? Well the long and short of it is this. This means that while trying to load an Export there was a dependency which could not be found during reflection.

The quick way to determine the cause of the error is to do as the image below shows:

What I would suggest is to wrap your MEF logic inside of a try-catch and explicitly catch ReflectionTypeLoadException. Inside of your catch add some logic as such (just a PoC, copy-paster beware).

catch (ReflectionTypeLoadException tLException)
{
    var loaderMessages = new StringBuilder();
    loaderMessages.AppendLine("While trying to load composable parts the follwing loader exceptions were found: ");
    foreach (var loaderException in tLException.LoaderExceptions)
    {
        loaderMessages.AppendLine(loaderException.Message);
    }

    // this is one of our custom exception types.
    throw new PluginLoadingException(loaderMessages.ToString(), tLException);
}

As you can see when you look at the LoaderExcpetions collections from my image above I had forgotten to reference AutoMapper in my plug-in and all hell broke lose (btw, no idea how this even compiled, but that is a different post).

Hope this helps.

Till next time,

Duplicated columns in generated sql from NHibernate

Derik Whittaker — Mon, 25 Jan 2010 13:57:25 GMT

I was trying to profile some NHibernate sql to see if we could make some improvements. One thing I noticed very shortly after starting this task was that one of my columns was being duplicated. Now this is NOT going to make a huge performance difference but was something I wanted to remove this as it felt ‘wrong’. Below is the original sql segment

resrole1_.PART_B_PROVIDER_NO             as PART16_29_0_,
resrole1_.ADMIN_SET_ID                   as ADMIN17_29_0_,
resrole1_.NATIONAL_PROVIDER_ID           as NATIONAL18_29_0_,
resrole1_.Admin_Set_ID                   as Admin17_29_0_,
resrole1_.Resource_Type                  as Resource19_29_0_,

The first thing I looked at when I started to look for the cause was the mapping for the entity (Role entity) to make sure the ‘Admin_Set_ID’ is not mapped multiple times. And of course it was not. After a few minutes of staring at the screen (everyone knows this is how all the hard problems are solved) it dawned on me that Admin_Set_ID was a FK from one of my associations. Below is my association that was using it.

References( x => x.ResourceType )
	.Access.AsCamelCaseField( Prefix.Underscore )
        .WithColumns( "Admin_Set_ID", "Resource_Type" )
        .FetchType.Select()
        .LazyLoad();

Because Admin_Set_Id is a FK I should NOT have been mapping as part of my entity. When I removed this column from my entity so that I could get it as part of my association. When I did this my newly outputted sql looked like below:

resrole1_.PART_B_PROVIDER_NO             as PART16_29_0_,
resrole1_.ADMIN_SET_ID                   as ADMIN17_29_0_,
resrole1_.NATIONAL_PROVIDER_ID           as NATIONAL18_29_0_,
resrole1_.Resource_Type                  as Resource19_29_0_,

Long story short is this. If you happen to see a column being duplicated in your generated sql make sure that you are not referencing/mapping a FK directly in your mappings.

Hope this helps.

Till next time,

Passing NULL into Overloaded Methods in unit tests…

Derik Whittaker — Thu, 21 Jan 2010 12:08:31 GMT

Today I was adding some new logic to some older code and I noticed there was very little test coverage on the logic so I decided to add some. As I was adding coverage I wanted to add some tests that proved out our Contract style bound checks. However there was one slight problem. The method(s) I wanted to add coverage to was overloaded as such:

public virtual IMessageTransporter GetTransporter( Destination destination )
{
    // The null transporter will allow for testing without hittng rhapsody or an engine
    if ( ConfigurationReader.UseNullTransporter ) { return new NullTransporter(); }

    Contracts.Requires( destination != null );
    
    // for now we only have one transporter for now.... will add more later
    return new HttpTransporter( destination.Endpoint );

}

and

public virtual IMessageTransporter GetTransporter( Endpoint endpoint )
{
    // The null transporter will allow for testing without hittng rhapsody or an engine
    if ( ConfigurationReader.UseNullTransporter ) { return new NullTransporter(); }

    Contracts.Requires( endpoint != null );
    
    // for now we only have one transporter for now.... will add more later
    return new HttpTransporter( endpoint  );

}

As you can see from the 2 methods above they are the same with ONLY the provided parameter being different. When I started to write my tests I did this:

transporterFactory.GetTransporter( null );

But when I simply added NULL as the parameter the compiler provided me the following error

The call is ambiguous between the following methods or properties: ‘TransporterFactory.GetTransporter(Destination)' and TransporterFactory.GetTransporter(Endpoint)' C:\PathHere\TransporterFactoryTests.cs 13 45 Common.Tests

Now if you think about it for even 2 seconds the above error makes perfect sense. So the real question is how do you get around this….? Simple you do the following.

transporterFactory.GetTransporter( (Destination)null );

By providing a type on your call the compiler now will know which overload you are attempting to call and the world will be a happier place.

Till next time,

A new feature request for C# I would like is fall through exceptions

Derik Whittaker — Wed, 20 Jan 2010 23:58:16 GMT

Now before you write off this post as being ‘just another silly request’ hear me out.

Right now in C# we can do the following

switch( someObject )
{
	case Option1:
	case Option2:
	case Option3:
		// do something
		break;
	case Option4:
		// do something
		break:
}

Allowing fall through for a switch statement is a powerful technique. It allows for multiple case statements in the same switch block to use the exact same logic, oh, and it also allows for code reduction.

Given the fact that we can do this with a switch statement why can we not do this with try-catch statements?

As an example(s) (or a suggestion of syntax) why could we not have the following

try
{

} catch ( SomeException1 ) {
} catch ( SomeException2 ) {
} catch ( SomeException3 ) {
} catch ( SomeException4 se ) { 
	// do something
} catch ( SomeException5 se ) {
	// do something
}

try
{

} catch ( SomeException1, SomeException2, SomeException3, SomeException4 se ) { 
	// do something
} catch ( SomeException5 se ) {
	// do something
}

I know, I know you think I have lost my mind. But think about it. There are times when you want to handle multiple exception types with the exact same logic. However today when you do this you are forced to either create a helper method to handle the logic or repeat the logic over and over again. If we had the ability to allow for fall through exceptions we could reduce duplicated code and reduce code noise.

Now before you start asking questions like … let me provide some quick Q & A

Q) If you do this you will never be able to know exactly what type of exception was thrown.

A) You are correct, but in this scenario do you really care about the exception type? If you did I am going to guess you would break it out into individual catch block

Q) When would this situation actually be practical?

A) Consider this. You are creating a connection to a 3rd party resource (web service, wcf, api, etc) and that connection can throw a few different exceptions. In some cases if the expected exception is throw you want to log and maybe roll back a transaction or something. In this case i do not want to re-throw (or just let bubble up) the exception, but at the same time I do not want to duplicate my code.

So, let me have it. Tell me how dumb this is.

Tell next time,

NHiberante and Join types in your mappings Select vs Join

Derik Whittaker — Mon, 11 Jan 2010 20:34:30 GMT

When you are setting up your NHibernate mappings you must pay close attention to the way you setup your relationships between your entities. Recently I started profiling some of our statements and was shocked to see how some of them had a metric-crap ton of joins when they only needed one or two. After a bit of looking I realized that we had explicitly set FetchType to .Join (via Fluent NHibernate) and this was a big no-no.

When you setup your associations to be join associations each time you use a entity you will get (for free :) ) the associations for that entity. However, as you may guess this can be very, very expensive and not the desired outcome. Below is how changing my FetchType from .Join to .Select (also, .Select is the default if you do not specify any FetchType).

This is the SQL output when everything was setup for .Join

FROM   RES_Basic this_
       inner join Res_Role roles1_
         on this_.RESOURCE_ID = roles1_.RESOURCE_ID
       left outer join O_BRANCH branch4_
         on roles1_.BRANCH_ID = branch4_.BRANCH_ID
       left outer join A_PROVIDER_TAXONOMY providerta5_
         on roles1_.TAXONOMY_ID = providerta5_.TAXONOMY_ID
       left outer join O_TEAM team6_
         on roles1_.TEAM_ID = team6_.TEAM_ID
       left outer join RES_Basic resource7_
         on roles1_.RESOURCE_ID = resource7_.RESOURCE_ID

This is the output after we changed to .Select (and setup my criteria to explicitly reference my Res_Role table)

FROM   RES_Basic this_
       inner join Res_Role roles1_
         on this_.RESOURCE_ID = roles1_.RESOURCE_ID

As you can see, when I do it right I am only joining to the tables I want and this can lead to a huge performance savings.

Till next time,

NHibernate and “The multi-part identifier … could not be bound” Exception

Derik Whittaker — Tue, 05 Jan 2010 12:48:42 GMT

Today as I was creating a new NHibernate Criteria statement everything was working fine UNTIL I added the where clause. At this point I started to get the following exception (which was seen via NHibernate Profier).

WARN:
System.Data.SqlClient.SqlException: The multi-part identifier "doc2_.NAME" could not be bound.

My criteria statement looked something like this

var query = Session.CreateCriteria( typeof(DocumentSection), "docSection" )
    .CreateAlias( "docSection.DocumentSegment", "docSegment", JoinType.None )
    .CreateAlias( "docSegment.DocumentDefinition", "doc", JoinType.InnerJoin )
    .... MORE STUFF HERE

    .Add( Restrictions.Eq( "doc.Name", documentName ) )

    .SetResultTransformer( new DistinctRootEntityResultTransformer() )
    .List();

When I first saw this error it did not make any sense as I KNEW that there was in fact a Name field on the object I was trying to hydrate. But if you look closely at the first .CreateAlias you will notice the issue. For my JoinType I had set it to JoinType.None and not JoinType.Inner so when NHibernate wanted to hydrate my object it could not because as far as it was concerned the object was not meant to be hydrated.

To resolve this issue I changed the JoinType to be Inner and all worked. Below is the working code.

var query = Session.CreateCriteria( typeof(DocumentSection), "docSection" )
    .CreateAlias( "docSection.DocumentSegment", "docSegment", JoinType.InnerJoin )
    .CreateAlias( "docSegment.DocumentDefinition", "doc", JoinType.InnerJoin )
    .... MORE STUFF HERE

    .Add( Restrictions.Eq( "doc.Name", documentName ) )

    .SetResultTransformer( new DistinctRootEntityResultTransformer() )
    .List();

Till next time