Archive, ASP.NET
     

Comparing Deployed ASP.NET Sites With NDepend

Few things compare to the experience of inheriting an existing software project when (for whatever reason) none of the original developers are with the company. I have been in the situation a couple of times myself and it never fails, you inherit the code base just in time to fix a bug or implement a new feature.

One of my concerns whenever this happens is whether the deployed version of the website matches the latest version in source control. In an ideal world the source control system would have been tagged when the last deployment took place and their would be little guess work. But live is seldom this ideal. In reality their is often no indication of when and what was last deployed into production short of the binaries residing on the server.

Fortunately NDepend has a lot of powerful features that help with this exact predicament. For those of you who have never used NDepend it is a very powerful static code analysis tool for .NET, and contains more features than I could possibly do justice to here. For those interested Scott Hanselman wrote a great review here, and there are also several screencasts on the NDepend website.

Comparing Binaries

To demonstrate this I am going to compare my currently deployed blog (which I happen to know is running dasBlog version 2.3) to a known version of dasBlog 2.2. To get started make sure you have local copies of both sites you want to compare, and fire open your copy of NDepend.

To compare source files you do not need to even create a project file. You simply need to select “Choose Assemblies or Analysis to Compare” from the “Compare” menu of the Visual NDepend GUI.

For this demonstration I am going to compare only the newtelligence assemblies shipped with dasBlog, but you will want to compare the assemblies to represents you own custom code. For example, if you consumed the NHibernate ORM you wouldn’t want to necessarily compare NHibernate.dll.

Once you have selected the assemblies you want to compare and clicked “OK” NDepend will begin the process of analyzing the assemblies. Depending on the number and size of the assemblies this could take a few moments. But as a reward for your small wait you will be soon greeted by more than enough code metric to keep even the most scrutinizing of people happy.

Mining The Results

Once the code analysis has been performed we can begin the task at hand of finding the differences between the two versions of the site. For this task their are two areas of the main screen that are of concern. The Class Browser and the CQL Queries window.

The Class Browser is very intuitive for anyone familiar with Visual Studio and simply provides a high level overview of Assemblies, Namespaces, and Types. For instant gratification NDepend kindly provides via a context menu option. From the Class Browser right-click on one of the assemblies you compared and select “What was changed?” and then “SELECT METHODS FROM ASSEMBLIES … WHERE CodeWasChanged”. In place of the Class Browser you will see a list of methods that are different between builds.

Behind the scene NDepend issue what it calls a CQL (Code Query Language) query against its internal database it compiled during the code analysis. This database contains all kinds of helpful information about your source code. Using CQL we can do much more than just select methods that have changed. We can apply any number of constraints to what is returned. For example, you may not be concerned about unused methods even if they do differ. Using CQL you can word that like:

SELECT METHODS FROM ASSEMBLIES "newtelligence.DasBlog.Web" 
WHERE CodeWasChanged AND (
 MethodCa > 0 OR
 IsPublic OR
 IsEntryPoint OR            
 IsExplicitInterfaceImpl OR 
 IsClassConstructor OR      
 IsFinalizer                
)

Or perhaps you only want to see methods that are private that have changed.

SELECT METHODS FROM ASSEMBLIES "newtelligence.DasBlog.Web" 
WHERE CodeWasChanged AND !IsPublic

There is a nearly unlimited amount of flexibility that CQL provides, and it is through this one feature that NDepend gains its power.

Conclusion

There are more features to NDepend than I could possibly do justice to here, but it ability to compare assemblies is my favorite. When I first discovered this feature of NDepend my jaw literally dropped. I had been wishing for this capability from a tool for a long time and my wish had just come true. What once was a nightmarish task of comparing some unknown binary build of a site to code base has been made much easier thanks to NDepend.

Never miss an article! Subscribe to my newsletter and I'll keep you updated with the latest content.

 

About Jason

Jason is an experienced entrepreneur & software developer skilled in leadership, mobile development, data synchronization, and SaaS architecture. He earned his Bachelor of Science (B.S.) in Computer Science from Arkansas State University.
View all posts by Jason →

Leave a Reply

Your email address will not be published. Required fields are marked *