Its late, so this will be a short post.
Version 1.3 of aspNETserve has just been released. It can be downloaded from http://code.google.com/p/aspnetserve/downloads/list.
Version 1.3 has several important enhancements and bug fixes. In a future post (hopefully in a day or so) I will go into detail of all the changes, but for now there is always the release 1.3 ticket view on the project’s issue tracer.
The RedirectToAction allows a controller to do an HTTP redirection to an alternative action. This is essentially the MVC equivalent of just doing a Response.Redirect in ASP.NET.
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(...)
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:
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.
In my last article I discussed how to use a wild card route to capture completely malformed URLs. But what if a URL matches to a controller in which the requested action cannot be found?
For example, when a visitor requests http://example.com/product/listing when there is no listing action on the product controller. In this example your visitor would be greeted by the a less than friendly page stating:
Server Error in '/' Application. The resource cannot be found. Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Custom file not found (404) error pages can help to create a more rewarding user experience for your site visitors. Links become outdated and there is nothing more frustrating for a user than to have found a link to exactly what they are looking for and to come across the infamous “file not found” screen.
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:
Contracts, both explicit and implied, are key in designing a working software system. An example of an explicit contract in C# would be the implementation of an interface, while an implied contract would be something along the lines of all business objects have default constructors. Contracts of both types are critical to the success of a software system, but how do you test for and enforce these contracts?
Explicit contracts are often enforced by the compiler and are not nearly as fragile as implied contracts. Using the ContractTest testing framework you can write test cases for many common implied contracts. You can incorporate ContractTest assertions directly into your existing unit tests. For the following examples I will be using NUnit syntax, but you could use most any other unit test framework.
For example, assume you want to test for the presence of a publicly accessible default constructor on one of your business objects. Such a test using ContractTest would look like.
using ContractTest.Assertions; using NUnit.Framework; using MyNamespace.BusinessObjects; [TestFixture] public class SampleTests{ [Test] public void Test1(){ ContractAssert.Type.HasPublicDefaultConstructor<BizObjectA>(); } }
Sometimes it is handy to have the HttpSession available from your custom IHttpHandlers. By default the session state is unavailable from IHttpHandlers, and attempting to access it will result in a NullReferenceException. To make session state available simply implement the IRequireSessionState interface.
using System.Web; using System.Web.SessionState; public class SomeHandler : IHttpHandler, IRequiresSessionState { public void ProcessRequest(HttpContext context){ //do processing that requires session state. //use the context.Session to acquire the session state. } public bool IsReusable { get { return false; } } }