In the past I have talked about the The Wonders Of InternalsVisibleTo and how such a simple attribute allows for internal components to be shared between different assemblies, opening the door to greater code separation and dependency control. In that previous article I illustrated how you can use the tool that ships with Visual Studio to get the public key signature from one of your existing dlls.
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(...)
In my previous post I discussed how to get ASP.NET MVC working with Visual Web Developer (VWD) Express 2008. At the time VWD did not support web application projects which are need for ASP.NET MVC.
Fortunately the upcoming service pack 1 for VWD adds support for web application projects and thusly support for ASP.NET MVC out of the box. Currently the service pack is in beta and can be downloaded from:
In my previous post I discussed a problem of developing ASP.NET 2.0 applications in Visual Studio 2005, while having the .NET 3.5 framework installed. In summation, the issue was because Visual Studio 2005 was linking against a library that shipped with .NET 3.5 instead of the explicitly referenced version from the web.config.
The comments of one reader of my previous post mentioned using binding redirection to resolve the issue. In short, it looks like they were correct. As best as I can tell, binding redirection does in fact fix this issue.
Binding redirection is the ability to take a pre-compiled application and tell the loader to link against a different version of a library than the application was originally built with. In our case, we would need to add the following configuration to our web.config.
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/> <bindingRedirect oldVersion="22.214.171.124" newVersion="1.0.61025.0"/> </dependentAssembly> </assemblyBinding> </runtime>
As many of you have, I also have experimented with the pre-releases of .NET 3.5 and Visual Studio codenamed Orcas. I, for better or worse, installed this pre-release software on my primary development machine which has Visual Studio 2005.
Despite having .NET 3.5 installed on my machine, my primary development occurred in .NET 2.0 via Visual Studio 2005. I had not experienced any problems with this setup until the other day. While attempting to build and publish an ASP.NET 2.0 website with AJAX extensions, I ran into a cryptic server error when executing the site on a staging server. The error was:
Could not load file or assembly 'System.Web.Extensions, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
or one of its dependencies. The system cannot find the file specified.
The System.Web.Extensions assembly is the ASP.NET AJAX assembly, so at first I simply thought that the staging server did not have AJAX extensions installed. After installing the AJAX extensions, the issue remained unresolved. A quick look in the machine’s GAC showed that it had version 1.0.61025.0, which is the latest version. Inspection of my development machine’s GAC showed both 1.0.61025.0 and 188.8.131.52 installed.
At this point I was puzzled how my machine had an unofficial version of AJAX extensions, and how my website was referencing it. Next I looked at the web.config of my site to see if I could just change the referenced version to 1.0. However, inspection of the web.config reveled:
<add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
I have wondered for a long time how to access a Types XML comment data at run-time. I know that comments are normally thrown away in languages, but I figured that .NET must keep the XML comments around somewhere, how else could they display the information through intellisense for user created DLLs.
Well, according to this article that I just found, the XML comments are thrown away like all other comments at compile time.
It seems that intellisense attempts to load a separate .XML file to display the comments.