About Me

My name is Nick Olsen and I am currently working as a software developer on an application that is used to manage tenants in apartment complexes. My language of choice is C# in Windows, ASP.NET Web Forms, and MVC. My latest dabblings have been with Android Applications, ASP.NET AJAX enabled websites, ASP.NET MVC, Silverlight, and HTML5.

By default new ASP.NET MVC projects redirect any unauthenticated users who request resources that require authentication to the /Account/LogOn action. The log on page is defined in the web.config authentication section.

After the change I tried accessing a page that required the user to be authorized with and unauthorized user and to my surprise, the site redirected me to /Account/LogOn and I got a 404 error saying the the resource could not be found. It turns out this is a known issue with the ASP.NET MVC when the WebMatrix.Data.dll and WebMatrix.DataWeb.dll are added to the deployable assemblies collection. This issue can be fixed by adding the following key to the appSettings section of the web.config.

I use Moq extensively when unit testing my applications. One of the nice features of Moq (and any other Mocking framework) is that you can verify which methods were called on a given interface during a test. By default, if you have a method on an interface that accepts parameters and you want to verify that it is called, you have to specify the exact parameters that should have been used in the method call for it to pass the test. Example:

If you need to test the actual data be passed to the Add method you can do this but if you just want to test whether or not the method was called regardless of the parameters supplied to the method, you can using Moq. To do this, just use It.IsAny method supplied by the Moq framework to indicate that you just want to see if the method was called with any type of Company object.

In on of my recent ASP.NET MVC projects I was implementing the UnitOfWork pattern while utilizing the Entity Framework Code First approach for data access. I have seen many examples of the UnitOfWork pattern where the repositories are actually contained within the UnitOfWork class but since the Entity Framework already supports the UnitOfWork pattern out of the box, I decided to go with a different approach.

Using the Entity Framework Code First approach, a class inheriting from the DbContext class is created and is used to handle all the database interaction. Whenever you perform any work using the DbContext, the changes are not actually persisted to the database until you call the SaveChanges method. As I said, the UnitOfWork pattern already implemented. To enforce the UnitOfWork pattern, I created an IUnitOfWork interface and ensured that my DbContext class implemented that interface.

This allows the Controller to interact with any number of repositories and then after all operations are complete, to call the IUnitOfWork.Commit() method. Here is the issue. With this implementation, the IUnitOfWork instance supplied to the AccountController and the DbContext provided to the repositories all need to be the same instance of the DatabaseContext class for the UnitOfWork pattern to work. Here we my first attempt at doing this.

This definitely didn’t work as it created new instances of the DatabaseContext class for each repository and each IUnitOfWork. Using Ninject, to ensure that the same DbContext instance is used for all dependencies in a single http request, you simply need to add InRequestScope() to the end of the registration. So I tried the following.

This was closer as all the repositories were using the same DbContext but when the Controller requested an IUnitOfWork, Ninject created a new instance of the DatabaseContext class and thus the IUnitOfWork pattern did not work. I needed to somehow ensure that the same instance of the DatabaseContext class was used for all DbContext and IUnitOfWork requests. After some research, I figured out that the following code will resolve the problem.

In the code above, we are first binding the DatabaseContext class to itself indicating that only one instance should be created per http request. This ensures that whenever a DatabaseContext instance is required, the same one is used. Then, to bind that same DatabaseContext instance to both IUnitOfWork and DbContext request, we need to bind those requests to a method which requests a DatabaseContext instance from the Ninject kernel. And that’s it!

Many have discussed the woes of working with the default ASP.NET SqlProfileProvider in a web application as the profile information is pretty much impossible to query. Gratefully another profile provider was developed, the SqlTableProfileProvider, that stores user profile information in a table format with one column per profile property. The code for that can be found here. But alas, there is still one more issue when using the SqlTableProfileProvider when developing an ASP.NET MVC application. Since it is a web application project and not a web site project, you lose the convenience of the strongly typed Profile object when coding. Again, another work around has been created that solves this problem here. Unfortunately the previously cited example assumes you are using the default SqlProfileProvider and not the SqlTableProfileProvider. I wanted to just name a few changes that need to be made when using the cited Profile Provider in an ASP.NET MVC application with the SqlTableProfileProvider.

First, since you are specifying the profile properties in the UserProfile class, you need to remove the profile property definitions from the web.config profile section. Instead of your profile section looking like this:

If you don’t remove the properties section, you will get a ConfigurationErrorsException at run-time saying “This profile property has already been defined.”

Second, while the UserProfile class will define which properties are available in the profile, you still need to specify the CustomProviderData information that gives the provider the column name and type for each property. To do this, just add the CustomProviderData attribute to each property in the UserProfile class.

In a recent project, I needed to ensure that a session variable was populated for every View. Using ASP.NET WebForms one could perform a check for the session variable in the Page_Load event of a master page but this obviously doesn’t work for the MVC Framework as there is no such page life cycle. Despite the lack of a “page life cycle” like WebForms, there is still a request life cycle in which a number of events are fired before and after the controller action.

To solve our problem we need to do two things:

Create a base controller from which all other controllers will be derived

Override the OnActionExecuting event in the base controller

In the following code I have done both the named items above. I have created a class named BaseController that extends the Controller class and have overridden the OnActionExecuting event which will fire each time an action method is requested. Within this event, you simply check the session variable you need populated and if it does not have a value, populate it.

Now when generating our Controllers for the application, instead of extending the Controller class, just extend the BaseController class we created above.

public class HomeController: BaseController
{
public ActionResult Index()
{
// Since we are extending from our custom BaseController class
// the OnActionExecuting event will be fired and the session variable
// will be populated
return View();
}
}

You can also simply override the OnActionExecuting event for a single Controller if the logic doesn’t need to span multiple Controllers but be care not to duplicate code if doing this.