Take advantage of Reference Paths in Visual Studio and debug locally referenced libraries

Are you using NHibernate or other open-source library in your project? I’m pretty sure that you are. Have you ever wondered what’s happening “under the cover” when you call Session.Get or perform a query? You probably did. The problem is that usually all the external assemblies are stored in one directory (libs, packages, reflibs etc.) with no symbol files or sources. In this post I would like to show you how you can benefit from project’s ReferencePath property and debug the source code of your libraries at any time you want.

Let’s assume that our projects are using NHibernate 3.1. We ran nuget (http://nuget.codeplex.com/) to setup dependencies and NHibernate libraries are now in $(ProjectDir)\packages\NHibernate.\lib\Net35. In the project file (.csproj) we probably have a following section:

<Reference Include="NHibernate">

We are also using code repository and our .csproj file is checked-in as well as the whole packages directory. One day we noticed that one repository (DAO) function is performing really badly. While debugging we found out that the problem lies in Session.Get method. Without knowledge of what’s happening inside we are not able to tell what causes this performance loss. But we also know that NHibernate library is open-source so let’s get the source code, debug it and have a grasp at what NHibernate gurus put in there. We download the source code (NHibernate-3.1.0.GA-src.zip), save them to c:\NHibernate-src and run the compilation script (NHibernate is using nant script, we want pdb files that’s why project.config=debug, I skipped tests just to speed up the build process):

nant -t:net-3.5 -D:skip.tests=true -D:skip.manual=true -D:project.config=debug

You probably will need to download ILMerge and place it in the c:\NHibernate-src\Tools\ILMerge. I also needed to remove c:\NHibernate-src\src\NHibernate.Test.build – somehow I was getting compilation errors and didn’t have time to check why (we won’t need the NHibernate.Test.dll anyhow).

The question now is how to bind the newly compiled assemblies (from c:\NHibernate-src\build\NHibernate-3.1.0.GA-debug\bin\net-3.5\) with our projects. There are two approaches: we can either replace NHibernate references in all projects and copy our debug-enabled binaries to packages\NHibernate.\lib\Net35 folder or use ReferencePath properties. First approach has many disadvantages – we are messing project files used by all developers (.csproj), source code is on our machine so other users won’t be able to debug NHibernate, on deployment we will need to restore all release-compiled binaries. When using ReferencePath we don’t have such problems. ReferencePath is your local project property and is stored in .csproj.user file which you usually don’t upload to the repository (and if you do, you shouldn’t ;)). Visual Studio considers ReferencePath in the first place (before HintPath) while looking for assemblies and so when you compile your project locally it will be bound with the debug-enabled assemblies. Just to finish the subject: you set the ReferencePath by right clicking your project in Solution Explorer, choosing Properties and then ReferencePaths tab:

Click “Add Folder” and a new section should appear in your .csproj.user file:


Now, while debugging press F11 on Session.Get and you should be able to step NHibernate source code. Have fun!

Take advantage of Reference Paths in Visual Studio and debug locally referenced libraries

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s