Archive, ASP.NET

Comparing Deployed ASP.NET Sites With NDepend

Jason / December 15, 2008

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 ) read more

.NET, Archive, ASP.NET, aspNETserve, C#

Community Coding Contest

Jason / October 1, 2008

Developing an open source project is a very rewarding experience. But sadly (as an open source developer that is) open source projects rarely get the feedback they deserve. Often the developers only hear feedback from their users when their software is broken, because of this it is often difficult to know when an author’s work is truly appreciated. read more

.NET, Archive, ASP.NET, aspNETserve, C#

aspNETserve 1.3: What’s New

Jason / August 19, 2008

As I mentioned in my last post, aspNETserve 1.3 has just been released. And with it comes some exciting changes. Here is an outline of some of the most notable changes:

HTTP Persistent Connections

aspNETserve’s goal is to target version 1.1 of the HTTP protocol, and prior to version 1.3 of aspNETserve it had an obvious shortcoming in that goal. It did not even attempt to keep “Keep-Alive” (aka, persistent) connections around. The server naively closed the connection after each request.

The new aspNETserve.Server object in version 1.3 has full support for persistent connections, and with it introduces a couple of new properties:

MaxConnections

This property represents the maximum number of simultaneous connections allowed. Once the maximum amount has been reached additional requests will be declined.

KeepAliveRequestTimeout

A period of time (in milliseconds) that aspNETserve will wait for subsequent communications on a previously established connection.

Windows Service Server

A Windows service called aspNETserve.Ice (pun intended) allows aspNETserve to process requests in the background. Additionally, this allows request processing without a user having to first login and launch the SimpleServer UI.

aspNETserve.Ice reads it configuration from an XML file whose schema is define on the wiki page ConfigSchemaOverview.

Here is a simple example of what the XML file looks like:

<?xml version="1.0" encoding="utf-8"?>
<server xmlns="http://aspnetserve.googlecode.com/svn/tags/Release%201.3/aspNETserve/Configuration/Xml/aspNETserve.config.xsd">
        <application physicalPath="c:\temp">
                <domain name="www.example.com" virtualPath="/" />
                <endpoint ip="127.0.0.1" port="80" />
                <endpoint ip="127.0.0.1" port="443" secure="true" />
        </application>
</server>
read more

Archive, ASP.NET, C#, Visual Studio

ASP.NET MVC: A Guided Tour

We’ve all read about what MVC is, but how does it really work? What are the nuts and bolts that make that MVC magic happen? Fortunately Microsoft has released the source code to ASP.NET MVC and we can read the details in all their glory. But if you are like myself reading source code is something far different than truly understand how an application works. Luckily since the source code has been released we can do much more than read it, we can use the debugger to step through it.

The debugger in Visual Studio is an extremely helpful tool for the modern developer. I often use the debugger as my first debugging route for development code. Interestingly enough we can put that same debugger to use to walk through ASP.NET MVC to get a better feel for how it operates.

The first thing we need to do is download the source code to ASP.NET MVC and compile it with debugging enabled. The source code can be downloaded from it’s CodePlex page. The download contains a Visual Studio 2008 project. Simply open the project and do a rebuild. Once completed you should see four files in the bin directory located directory in the folder you extracted the downloaded source code into.

Of those files we are only interested in two of them. System.Web.Mvc.dll and System.Web.Mvc.pdb.  Make note of where those files are located on your computer, because we will need to add a reference to those shortly.

In a new instance of Visual Studio lets create a new ASP.NET MVC application. The first thing we need to do is to delete the reference to System.Web.Mvc. Expand the references folder, and right-click System.Web.Mvc and select remove.

With the reference to System.Web.Mvc removed you will now need to add it back. Only this time instead of referencing the DLL that shipped with the ASP.NET MVC we will reference the DLL that we just compiled. By right clicking on the references folder and selecting “Add Reference…” you will be given the option to browse for the reference. Simply navigate to the path I asked you to remember earlier and select the System.Web.Mvc.dll file and click “OK”.

Now we are all ready to start debugging the innards of ASP.NET MVC. For starters navigate to the pre-generated HomeController and put a break point on the first line of the Index method.  Now start the site with debugging enabled.

Once everything gets done compiling and the application starts your Visual Studio instance should immediately stop at your break point.

At this point in your Call Stack window you should see entries for System.Web.MVC.DLL, and those entries should be in black (not gray). This means that Visual Studio has the debugging information that it needs to show us source code for those methods. This is precisely what we were trying for, Visual Studio will now all us to step through the ASP.NET MVC code in a very similar fashion to our code. Lets start by analyzing the call stack in detail.

In the call stack we see the following:

MvcApplication1.DLL!MvcApplication1.Controllers.HomeController.Index() System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters.AnonymousMethod(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters.AnonymousMethod() System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters(...) System.Web.Mvc.DLL!System.Web.Mvc.ControllerActionInvoker.InvokeAction(...) System.Web.Mvc.DLL!System.Web.Mvc.Controller.Execute(...) System.Web.Mvc.DLL!System.Web.Mvc.Controller.System.Web.Mvc.IController.Execute(...) System.Web.Mvc.DLL!System.Web.Mvc.MvcHandler.ProcessRequest(...) System.Web.Mvc.DLL!System.Web.Mvc.MvcHandler.ProcessRequest(...) System.Web.Mvc.DLL!System.Web.Mvc.MvcHandler.System.Web.IHttpHandler.ProcessRequest(...) read more

Archive, ASP.NET

ASP.NET MVC Authentication Roundup

As of preview 3 of ASP.NET MVC it appears that authentication has been left out of the framework. So until this feature is included it seems that Microsoft has left security as an exercise for the reader. Many developers have find creative solutions for securing their MVC application. Here are a few interesting links: read more

.NET, Archive, ASP.NET, aspNETserve, C#

aspNETserve Update

It has been a while since I have mentioned anything about aspNETserve, so I figured it was due time for an update. Since the last update in December of 2007 there wasn’t any activity until recently. Between being distracted with a plethora of personal and professional obligations the project took a back seat. read more