I’ll also be going through using Mercurial both on my system and pushing changes to the Codeplex site.

Cricket.Net Series:

• Part 1: Setting up the initial project
• Part 2: Design Discussion
• Part 3: Unit Testing

Unit Testing Thoughts
The idea behind unit testing is to write a very simple piece of code to test your business logic for one condition.  The test either passes or fails.  As you build your application, you may have hundreds or thousands of these tests.  By keeping them very simple, and not running any time intensive operations such as I/O, these tests will be able to execute very quickly and give you an indication that your program is working correctly.

Unit Tests become most useful when your application has been completed for a number of months and then a required change is needed.  As you modify your code, you can re-run your unit tests to make sure your new modifications have not broken your program in some other area.

The difficult part of unit testing is thinking of all the different angles to test your piece of code.

As you write your tests and develop your application, you will undoubtedly break some of the tests that you had previously written.  These will then need to be revised.  This is the process you will go through to fully flesh out your application and develop it from a user (of the code) perspective.

I usually begin by writing all my tests against the Controllers since that is the entry point to the things my application will do.  I also try to write tests against the requirements of the application only.  If you test all of an application’s requirements, then you are making sure the application is doing what your customer wants it to do.  There is no need to test 100% of the code you write.  As mentioned above, you will break unit tests as you develop your application and continually have to revise them.  Revising tests that cover 100% of your code could be very time-consuming.

Unit Test Controller Shell
Since we’ll be testing Requirements, the first thing I do is create a new folder in the Unit Test project called Requirements.  There is currently a Controllers folder that we will remove later on.

Next, create a new Class item called ApplicationControllerRequirements.

The new class will need to be modified for unit testing. Below is the basic shell for a unit testing class.

using System.Web.Mvc;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Cricket.UnitTests.Requirements
{
  [TestClass]
  public class ApplicationControllerRequirements
  {
    [TestInitialize]
    public void Setup()
    {
      //This method runs before each test method.
    }

    #region Test Group

    [TestMethod]
    public void unit_test_method()
    {
      //Arrange.

      //Act.

      //Assert.
    }

    #endregion
  }
}

There are three attributes being used on this class: TestClass, TestInitialize, and TestMethod.

• TestClass – Signals this is a unit testing class.
• TestInitialize – This is an initialization method that is executed before each test method.
• TestMethod – This is a unit test function.

A unit test only tests one condition and there may be many conditions we need to test for, so I like to group my tests together using regions. These can be collapsed out of the way within Visual Studio to make it easier to work on other unit tests without the unwanted ones getting in the way.

Within a test method, there are three things that need to be done:

• Arrange – This consists of any mocking or setup tasks.
• Act – This is the execution of the action you are testing.
• Assert – This is the verification you received the desired result.

Writing The First Unit Test
First we will start with a very simple test against the Index action of the controller. This is the default action that is called if none is specified in the application’s URL.

We’re going to test if the Index controller returns a ViewResult. Notice the compiler now has an error on the “controller” object. This is because we haven’t created it yet. One nice aspect of TDD (Test Driven Development) is you think about how the interface to your code is used, and then develop the code afterwards.  Now we know we need to create a “controller” object and it needs to have a method called “Index”.

Since the initialization of the controller will need to be done for nearly all tests in this class, we’ll add that to the Setup() method.

Now the compiler is showing errors on the “ApplicationController” class.  We need to create the new controller in the main project.

• Right-click on the Controllers folder in the main project.
• Select Add, then Controller.
• Type in the Controller Name: ApplicationController and click Add. (Leaving the Template set on Empty Controller)
• In your unit test class, add the using statement: using Cricket.Controllers;
• Under the Unit Test method, add a cast to the “Act” line: ViewResult result = (ViewResult)controller.Index();
• Also, don’t forget to change the name of your unit test method to something meaningful. The more description you can put in this method name, the better.

Running Your Test
Ideally, you want to see your test fail first, to make sure you didn’t accidentally write a test that can never fail.

We can quickly test this by adding the following line to our Index method on the ApplicationController:

return RedirectToAction("Index");

A ViewResult is expected in the test, so now it will fail.

After you have verified the test has failed, change the Index method back to the following:

        public ActionResult Index()
        {
            return View();
        }

Now, your test should pass.

Another Test
Next, we’ll add another very simple test to verify the correct view is being returned from the Index method.

        [TestMethod]
        public void index_action_should_return_the_index_view()
        {
            //Arrange.

            //Act.
            ViewResult result = (ViewResult)controller.Index();

            //Assert.
            Assert.AreEqual("Index", result.ViewName, "result.ViewName");
        }

Running this test will fail because the Index method is not returning a specific view. To change this, modify the Index method to show:

        public ActionResult Index()
        {
            return View("Index");
        }

Now the test will pass because we are specifying a view to display.

Final Thoughts
Unit Testing does take some time to get the hang of it. It is well worth it in the long run to know you can modify your program to add new features without breaking the current functionality.

As we develop this application, these tests will become more complex, but by focusing on one result and writing multiple tests for each action, we can work through it.

The empty “Arrange” comment for each of these tests is a place holder for mocking objects we may need to place there in the future. Typically, Unit Testing developers say to place all setup code in the arrange.  I like to place common setup tasks that will happen for each test in the “Setup” method where I only have to code them once.  If there is a specific setup task needed for a single test, then I will place that under the “Arrange” comment.

Visit the project site at: http://cricket.codeplex.com.
Download the source code from this post at:
http://cricket.codeplex.com/SourceControl/changeset/changes/df77b3e9d546

I’ll also be going through using Mercurial both on my system and pushing changes to the Codeplex site.

Cricket.Net Series:

• Part 1: Setting up the initial project
• Part 2: Design Discussion
  Part 3: Unit Testing

What will the application do?
I’m going to take a step back before continuing with the code and look at what this application is suppose to do. I don’t need to determine everything up front, instead I’m going to use an Agile approach and lay down some basic requirements for what the system is suppose to do and if those change as the development progresses, that is fine.

Ususally the first thing I do is think about what information the application needs to store. Cricket.Net is a bug tracking program, so it will need to store information on a specific bug and what application the bug occurred in. I’m also going to want to track dates for when the bug was created and resolved, the version of the application the bug occurred in and maybe a list of one or more assignees who are working on resolving the bug.

Next, I’m going to open up Visio and separate these ideas into objects on a database model diagram. Since I’ve already created my solution folder, I’m going to add a folder within it called !Design. I’ll place all of my design files here to keep them with the solution when I update the Mercurial repository.

You don’t necessarily need to create a diagram of the database, you could just write-up the code using Entity Framework: Code First, but it is nice for non-programmers to have something to look at. Also, complex databases with many relationships can be difficult to work with if you don’t have a diagram to look at.

Onion Architecture and StructureMap
Now I’d like to talk for a minute about the Onion Architecture.  Structuring an application in this way separates the business logic from the web and infrastructure components in a way that limits their dependencies on each other. Take a look at the following diagram:

The blue boxes represent a project within the solution. The arrows point to their dependencies. Notice how all projects depend on Core. This is where the business logic classes and interfaces are found. Also, notice how the Web project (in this case will be MVC 3) does not depend on Infrastructure (where the database repositories reside). There is an indirect dependency through the DependencyInjection project. This is where StructureMap (or another IoC framework) lives. StructureMap will wire-up the dependencies between the Web and Infrastructure frameworks using the interfaces found in the Core project.

Why go through all this work to setup your project this way? Encapsulation of components that could be replacable in the future makes it easy to upgrade an application to those new componenets. With Onion Architecture you could switch the entire application over to a different database server and only have to modify the database classes found in the Infrastructure project. As long as the interfaces do not change for those classes, the reset of the application will work as it did previously. This can save much time over rewriting the entire application because the db code is embedded everywhere.

The UI component could be changed as well (in this case the Web project) for a console application. The Core and Infrastructure will function the same, but the application would appear totally different.

Projects Summary:

• UnitTests – As the name implies, it contains all unit testing code. The Moq mocking framework will be used here.
• Web – This is the user interface project. This contains the controllers, views, view models, and wrapper classes around MVC or web specific operations.
• Core – This contains all interfaces for the application and business logic including: the domain model and service classes.
• DependencyInjection - This contains the classes needed by StructureMap. StructureMap will register all interfaces and concrete classes used in the application.
• Infrastructure – This contains any IO wrappers or classes using 3rd party projects (including our own common projects).

Unit Testing
When starting a project, I try to get in the habbit of coding a Unit Test first, before anything else. This helps me think about how I want to use a method before I worry about how the method works. This tends to lead to an overall better design of the application. I also try to adhere to the SOLID principles, DRY, and YAGNI by only coding what is needed at the time.

Unit Tests should also be very simple. Test for one condition to be met and pass or fail.

Requirements

• Allow users to manage Applications (including adding different versions for each).
• Allow users to manage their issues.
• Allow users to be managed by users.
• (Managing each of these includes listing, adding, creating, editing, and deleting).

Visit the project site at: http://cricket.codeplex.com.
Download the source code from this post at: http://cricket.codeplex.com/SourceControl/changeset/changes/a115ce901573

I’ll also be going through using Mercurial both on my system and pushing changes to the Codeplex site.

Cricket.Net Series:

• Part 1: Setting up the initial project
• Part 2: Design Discussion
• Part 3: Unit Testing

Prerequisites
To get started, I’ll be using Visual Studio 2010 SP1Rel and ASP.NET MVC 3 Tools Update. Later, I’ll be using Entity Framework 4.1 Update 1 so that I can use Code First. You can either download and install Entity Framework, or we’ll attempt to install this from the Nuget package first.

Creating A New Project
Initially, I’m going to start with the basic MVC package created by Visual Studio. After this package is created, I’m going to create the Mercurial repository so that I can send the code to Codeplex.

1. Open Visual Studio 2010.
2. Click the File menu, then New, Project.
3. In the New Project window, under Installed Templates, expand Visual C# and choose Web. Select the template called “ASP.NET MVC 3 Web Application.” The Name field will be the default name and namespace of your initial project, the Location will be the folder on your C:\ drive where to store your solution, and the Solution Name is the name of your solution folder (if you wish it to be different).
   
4. After clicking OK, the New ASP.NET MVC 3 Project window pops up. I’m going to choose Internet Application so that the tooling will allow me to go ahead and create a Unit Test project also. I’m going to change the name of the Unit Test project to Cricket.UnitTests.
   
5. After Visual Studio finishes creating the project, it should look like the image below. The Internet Application template that we had chosen in the previous step has added some files that will may or may not use, but for now we’ll leave these in the solution and move on to creating the Mercurial repository.
   

Setting up the Mercurial Repository
If you are unfamiliar with Mercurial, it is a source control application that is very fast and pretty easy to use. Before you can continue with this tutorial, you will need to install at least TortoiseHg to manage the Mercurial repository from Windows Explorer.  If you’d also like to work with it from within Visual Studio, you will need VisualHg.  If you’d like to know more about what Mercurial can do, check out this video from tekpub.com.

1. If you still have your new solution open in Visual Studio, go to the File menu and choose Close Solution.
2. Next, browse to the folder where your solution folder is located. (In my case, I need to go to the C:\Users\cjackson\Documents\All Projects\ folder)
3. Right-click on the Cricket.Net folder and expand the TortoiseHg context menu and choose Create Repository Here.
4. TortoiseHg will display an Init window. Click the Create button to create the repository.
5. After the repository has been created, a green check mark icon will appear over the Cricket.Net folder icon.
6. Open the Cricket.Net folder and then edit the .hgignore file. This file will tell the repository to ignore certain files/folders that are used by Visual Studio and do not need to be version controlled. Paste the text below into the file and save it.

# use glob syntax
syntax: glob

*.obj
*.pdb
*.user
*.aps
*.pch
*.vspscc
*.vssscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
*.lib
*.sbr
*.scc
[Bb]in
[Dd]ebug*/
obj/
[Rr]elease*/
_ReSharper*/
[Tt]humbs.db
[Tt]est[Rr]esult*
[Bb]uild[Ll]og.*
*.[Pp]ublish.xml
*.resharper

Next, I’ll save the initial project into the Mercurial repository.

1. Return to the folder where your solution is stored. (C:\Users\cjackson\Documents\All Projects\ folder)
2. Right-click on the Cricket.Net folder and choose Hg Commit…
3. The Cricket.Net commit window will pop up. On the left pane, click the check box at the top to select all files then in the top-right pane, type in a comment for the commit. After you enter whatever comments you wish, click the Commit button to save the current state of the solution.
   
4. Next, for new untracked files, a window may pop up asking to add untracked files. Click Add.

To save the current repository to Codeplex, follow these instructions:

1. Return to the folder where your solution is stored. (C:\Users\cjackson\Documents\All Projects\ folder)
2. Right-click on Cricket.Net and expand the TortoiseHG context menu and choose Synchronize.
3. Under Remote Repository, change the drop down to HTTPS and enter the name of the repository so the URL looks like this (http://hg01.codeplex.com/cricket)
4. Click on the  icon to push changes to Codeplex.
5. Enter your Codeplex username and password when prompted and the files will be uploaded to Codeplex.

Visit the project site at: http://cricket.codeplex.com.
Download the source code from this post at: http://cricket.codeplex.com/SourceControl/changeset/changes/1569d75e695b#

Today I came across something new.  There were two different files that the client browsers from certain users were trying to access on the server.

- /_vti_bin/owssvr.dll
- /MSOffice/cltreq.asp

It appears that these are requests from a browser to look for web discussions on the site being accessed.  While this may be fine for a normal user’s browser, it is causing two exceptions to fire each time my application is being accessed.

To resolve this issue using ASP.NET MVC, I added the following code to the Global.asax.vb file at the beginning of the RegisterRoutes method:

routes.IgnoreRoute("_vti_bin/owssvr.dll")
routes.IgnoreRoute("MSOffice/cltreq.asp")

To use the remote debugger with ASP.NET MVC applications, you first must run the Visual Studio Remote Debugger Monitor on the server or remote computer.

There are two ways you can do this:

- Copy the monitor’s files to the server or remote computer
- Create a shared folder on your developer client and run the monitor on the server from the share.

I will go through the shared folder method. Share out this folder:
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger

If you server is running a 64-bit OS, use the x64 folder.  For the 32-bit OS, use the x86 folder.

Setting up the server

- Log into the server and navigate to the shared folder on your developer PC. 
- Go into the correct folder for your server’s OS (x86 or x64).
- Run the msvsmon.exe file.  If your server’s OS is Windows 2008, you will need to right-click on the file and run as Administrator.
- Open Tools -> Permissions.  Make sure that your developer client user is listed here.  If not, add the user and click OK.  Click Yes to allow the user to debug.
- Copy the name of the server (listed on the first line of the Visual Studio Remote Debugging Monitor).
- Return to your developer client.

Debugging remotely

- Make sure the latest version of your application is published to the server (so your source code will be the same as the executed code).
- From Visual Studio 2010, click Debug -> Attach to process.
- Change the value of the Qualifier field to the name of the server on the Visual Studio Remote Debugging Monitor and click Refresh.
- Under the Available Processes, select “w3wp.exe” and click Attach.  If you do not see this process listed, then open a web browser and run your application.  After your application has loaded, click the Refresh button and you should see the process.

* If you receive any error messages, you may need to:
- Click Build -> Clean Solution
- Click Build -> Rebuild Solution
- Republish your application to the server
- Click Debug -> Attach To Process

StructureMap is a dependency injection framework that makes it easy to create new instances of objects and even cache an instance of an object so various references to the object use the same instance. This is very useful with objects such as database connections.

You can download the library from the StructureMap Home Page. The example used in this post is using StructureMap 2.6.1.  I’m also using Visual Basic.  I had a tough time finding information on how to use StructureMap with Visual Basic, so hopefully, this will help someone else.

Setting Up MVC
When using StructureMap with ASP.NET MVC 1.0, I’ve found it works best if a folder is created in each project; Main, Data, and Service; where the StructureMap files are stored. This keeps them organized and makes them easy to find as you need to update them. A reference to the StructureMap DLL will need to be added to each project as well.

In the main project’s StructureMap folder, the following files are needed:

StructureMapControllerFactory

Imports System.Web.Mvc
Imports StructureMap

Public Class StructureMapControllerFactory
    Inherits DefaultControllerFactory

    Protected Overrides Function GetControllerInstance(ByVal controllerType As System.Type) As System.Web.Mvc.IController

        Return ObjectFactory.GetInstance(controllerType)

    End Function

End Class

This class sets up a factory class to get an instance of the StructureMap factory. It will be used to replace MVC’s default controller factory so that StructureMap will be in charge of creating our controllers.

BootStrapper

Imports StructureMap
Imports YourProject.Data
Imports YourProject.Services

Public Class BootStrapper

    Public Shared Sub ConfigureStructureMap()

        ObjectFactory.Initialize(AddressOf StructureMapRegistry)

    End Sub

    Private Shared Sub StructureMapRegistry(ByVal x As IInitializationExpression)

        x.AddRegistry(New MainRegistry())
        x.AddRegistry(New DataRegistry( _ ConfigurationManager.ConnectionStrings("iSeries").ConnectionString, _ ConfigurationManager.ConnectionStrings("Interbase").ConnectionString))
        x.AddRegistry(New ServiceRegistry())
        x.Scan(AddressOf StructureMapScanner)

    End Sub

    Private Shared Sub StructureMapScanner(ByVal scanner As StructureMap.Graph.IAssemblyScanner)

        scanner.Assembly("YourProjectNamespace")
        scanner.Assembly("YourProjectNamespace.Data")
        scanner.Assembly("YourProjectNamespace.Services")
        scanner.WithDefaultConventions()

    End Sub
End Class

This class is where StructureMap is configured. Within the StructureMapRegistry method, each AddRegistry call is made to include each of our project’s registry files, which have yet to be created. We will get to that in a moment, but notice that the DataRegistry is accepting values for connection strings. This is how information can be passed into a class being created by StructureMap when you would like to keep the configuration settings within the Web.config file.

Also, within the StructureMapScanner method, an entry needs to be made to scan each project’s namespace.

MainRegistry

Imports DCS.Data
Imports StructureMap.Configuration.DSL

Public Class MainRegistry
    Inherits Registry

    Public Sub New()

        [For](Of IWebContext)() _
            .Use(Of WebContext)()

    End Sub

End Class

Each project will have its own registry file where you can specify that Interface-A should create an instance of Class-A. In the example above, I want StructureMap to create an instance of WebContext (from the main project) when it comes across a reference to IWebContext. 

In the Data project’s StructureMap folder you will need:

DataRegistry

Imports StructureMap.Configuration.DSL
Imports Spartan.DAO.Database

Public Class DataRegistry
    Inherits Registry

    Public Sub New(ByVal iSeriesConnectionString As String, ByVal interbaseConnectionString As String)

    'Data Connections.
    [For](Of YourDataContext)() _
        .HybridHttpOrThreadLocalScoped _
        .Use(Function() New YourDataContext())

    [For](Of DB2Connection)() _
        .HybridHttpOrThreadLocalScoped _
        .Use(Function() New DB2Connection(iSeriesConnectionString))

    [For](Of InterbaseConnection)() _
        .HybridHttpOrThreadLocalScoped _
        .Use(Function() New InterbaseConnection(interbaseConnectionString))

    'Repositories.
    [For](Of IShiftRepository)() _
        .Use(Of ShiftRepository)()

    End Sub

End Class

The DataRegistry is interesting because we are passing in two connection strings from the Web.config file. The first data connection is for Microsoft SQL, the second for DB2 and the third for Interbase. The second and third are using the DB2Connection and InterbaseConnection classes which are home grown database connection class that I wrote.  All three of these database connections are being cached by using the .HybridHttpOrThreadLocalScoped property. Using this will make the database cached instance work for both your live program and your unit testing.

The entry under repositories is what all remaining entries would look like within the registry class. Since the data project contains our repositories, they would all be listed here.

And, in the Service project’s StructureMap folder you will need:

ServiceRegistry

Imports StructureMap.Configuration.DSL

Public Class ServiceRegistry
    Inherits Registry

    Public Sub New()

        [For](Of IShiftService)() _
        .Use(Of ShiftService)()

    End Sub

End Class

The service registry is similar to that of the main project. All service classes found in the service project would be listed here.

Changes to the Global.asax

The last thing to do is setup the Global.asax file to load StructureMap.  Make the following changes to the Application_Start method:

Sub Application_Start()

    RegisterRoutes(RouteTable.Routes)

    'StructureMap
    BootStrapper.ConfigureStructureMap()
    ControllerBuilder.Current.SetControllerFactory(New StructureMapControllerFactory())

End Sub

Now, the default controller factory used by MVC will be overridden by our StructureMapControllerFactory. When a controller is created, it will now use StructureMap.

So, how do you use this when creating a class? This is the easy part.

StructureMap will use the greediest constructor from your controller, meaning, if you have two constructors, the one with the most parameters will be used. Each parameter references an Interface and sets a class variable for the object.  StructureMap uses the registry classes that we setup to map an interface to a real object.

Example Controller

Imports YourProject.Data
Imports YourProject.Services
Imports StructureMap

Public Class ExampleController
    Inherits System.Web.Mvc.Controller

    Private _shiftService As IShiftService
    Private _webContext As IWebContext

    Public Sub New( _
        ByVal shiftService As IShiftService, _
        ByVal webContext As IWebContext)

        _shiftService = shiftService
        _webContext = webContext

        'Initialize service classes.
        _shiftSummaryService.Initialize(New ModelStateWrapper(Me.ModelState))

    End Sub

    ...

All that you need to do is create a constructor, pass in all the interface references you need for the controller, then store them in a class variable. If you need to use the ModelState for validation within your service class, the best way I’ve found to do this is use an Initialize function in your service class to pass in the ModelState. This is because the ModelState is not yet created by MVC when the service classes are created by StructureMap.

When StructureMap creates the instance of the ShiftService, it will look at the greediest constructor from that class to create instances for any required parameters. This continues for all classes that are referenced.

Once the solution has been configured to use StructureMap, the only thing you’ll need to maintain will be the registry files as you add new classes and interfaces to your project. Don’t forget to add a registry entry or you will recieve an exception.

Here are some tips that I use to help keep my ASP.NET MVC solutions organized:

1. Use multiple projects to separate sections of the program.
2. Use folders to group interfaces, classes, and factories that deal with an object.
3. If objects can be used by other programs, put them in their own class library project.

Option 1
When beginning a new program, I usually start by creating an ASP.NET MVC solution with 4 projects:

• The main project – which contains the MVC components of the application such as Controllers, Views, CSS, and JavaScript files.
• The unit testing project – which contains all of the requirements for the application along with any fake repositories used for testing.
• The data project – which contains the repositories and domain objects used by the application.
• The services project – which contains the service objects that are the middle-man between the Controller and the Repository.

Option 2
Folders are used within the projects to further organize the code files within. The data project could have a domain object called Operation.  Domain objects are placed in a folder with the same name as the object.  Interfaces, Repositories, and Factories that deal with the object are also placed in the domain object folder.

The service project is organized similar to the data project.

The unit test project is slightly modified from the default to create a folder which contains all fake repository objects and another folder to contain requirement tests. Depending on the detail of unit testing you wish to utilize, you may have unit tests that verify application requirements and/or unit tests that further verify other parts your code.

In my opinion, you can write application requirements that detail exactly what the program should do and as long as you unit test these requirements, you don’t need to waste time trying to unit test 100% of your program. If a bug is found later, it will most likely be because it was not an application requirement. Then, add a new requirement, write a unit test, and make the application pass the new test.

Option 3
Where I work, we have various databases that we need to communicate with. We wanted a way to use these databases the same way every time without having to remember all of the different objects and names that needed to be used by each. So, I developed a parent wrapper class around the basic database functionality and then individual wrappers around each database object that inherited from the parent wrapper. Now, we can call up any of the database connections and work with them in exactly the same way, the only difference between them is the call to the factory when creating the instance.

These database wrappers were added to their own separate project so that in future applications, we could continue to reuse them.

Install ASP.NET MVC
Follow the first two steps of the instructions for installing ASP.NET MVC. The third step can be ignored since Visual Studio will not be installed on the server.

Configuring ASP.NET 2.0
First thing to do is open the IIS Manager ->expand your server ->Web Service Extensions folder. Right-click on the white space under the list of Web Service Extensions and select to Add a new Web service extension…

The New Web Service Extension window will pop open. Enter “ASP.NET v2.0.50727″ as the Extension Name and click the Add button.  Browse to the C:\Windows\Microsoft.Net\Framework\v2.0.50727 folder and select the aspnet_isapi.dll file. Make sure to check the “Set extension status is Allowed” button before clicking OK.

This will allow your programs to run ASP.NET 2.0, 3.0, and 3.5 versions of the .NET framework.

Configuring Your Web Application
The next thing to do is open the properties of the Web Site where your web application is. Select the ASP.NET tab and select 2.0.50717 in the ASP.NET version drop down box.

Next, click on the Home Directory tab. Click on the Configuration button. Under the Wild-card application maps area, click the Insert button. Browse to the C:\Windows\Microsoft.Net\Framework\v2.0.50727 folder and select the aspnet_isapi.dll file. Uncheck the “Verify that file exists” before clicking OK. Save your changes and your site should now be able to run ASP.NET MVC and use the routes setup by your application.

There are a few different options:

1. Build a separate Windows Service application that can connect to the assemblies your web application uses to execute the scheduled task.
2. Build a separate Windows application that communicates with a web service that your web application also uses to perform the scheduled task.
3. Use the Windows Scheduler to call the URL of the action to perform the task.

The first option might sound good at first, but creating a separate program that talks to your web application’s library files is a bad idea. Maintenance will become a problem as you change your web application. Since the code is in two places, unit testing will not tell you that the class library you just changed has now broken your scheduled tasks in your windows service. 

The second option is slightly better, but you still may have issues with changing your class library.

The third option is the one that I will show you how to configure. We will setup a VBS script that will perform a call to any web address we pass to it. Then, we’ll setup a batch file that calls the VBS script and passes in one or more URLs to execute. And finally, we’ll go through using the Windows Scheduler to create the scheduled task when the batch file should execute.

The primary advantage to this method is that you get to keep all of your code together in your web application. You simply setup an action that performs whatever task you wish to schedule and make sure that action is callable from an anonymous user.

WebRequest.vbs
You may copy the following code and paste into a text file. Then, rename the file to WebRequest.vbs. The script basically takes an argument that is passed into it as the URL. The HTTP object is setup and then the URL is called using a GET request. Then, the returned status is checked to see if the request was successful or not.

url = WScript.Arguments.Item(0)
'WScript.echo url

set WshShell = WScript.CreateObject("WScript.Shell")
set http = CreateObject("Microsoft.XmlHttp")

http.open "GET", url, FALSE
http.send ""

if (http.Status = 200) then

    WScript.echo "Request successful."

else

    WScript.echo "Error: " & http.Status

end if

set WshShell = nothing
set http = nothing

The Batch File
Calling the WebRequest.vbs file from a batch file is very easy. Simply create a new text file, calling it whatever you’d like, and paste in the following line of text. Rename the file to .BAT when finished.

cscript WebRequest.vbs "http://www.domain.com/controller/action"

Scheduling The Task
From your Windows server, open the Control Panel and then open the Scheduled Tasks item. Next, click on Add Scheduled Task. Choose any application to schedule.  This will be changed later on. Configure how often you wish the schedule to run and enter a user name and password to run the schedule as. This users should have access to running the web browser from the server.

After your new scheduled task has been created, open it. In the Run text box, type in the full path to your batch file. Then, in the Start In text box, type in the full path without the batch file name. You can also adjust your scheduled time from within here. Click OK to save the changes and your scheduled task should be ready.

You can test the Windows Scheduler by setting the scheduled time to a minute or two in the future and then waiting for it to execute. If you just wish to test your action, or manually run it, you can simply run the batch file.

1. Download ASP.NET MVC 1.0 from Microsoft’s website. Make sure to download the MSI file and the source code if you would like to see how it works.
2. Install the AspNetMVC1.msi file.
3. Open Visual Studio 2008 and go to:
   1. File -> New -> Project
   2. Under Project Types, select Web under either Visual Basic or C#
   3. Under Templates, select ASP.NET MVC Web Application
   4. Give your application a name and change its location if you wish

That’s it! Upon creating a new web application, the default MVC application will open.

Note:
ASP.NET MVC should also work using the free development tool from Microsoft, Visual Web Designer 2008.