Here is a demo project in C# that should get you started.  If I find the time, I’ll post details on how this was put together (but I think most developers will benefit more from running and stepping through the source code anyway).

Hope this helps someone.  Happy Programming!

ASP.Net MVC 1.0

ASP.Net MVC 1.0 was released in March 2009. Read this tutorial to start learning it. Note that ASP.Net MVC is bin deployable which is very nice if you don’t want to install anything on the production web server.

Inversion of Control and Castle Windsor

Castle Windsor 2.0 was just released this Summer after a very long development period. To start using it, go get the dlls and reference them in your project.

If you are completely new to the IoC pattern, go read James Kovacs’ article and watch these videos.  They will get a typical .Net programmer up to speed pretty fast. You should also go to the canonical source for IoC, but frankly I learned more from the other links and I think you will too.

To learn how to configure the Windsor container in your project, read the project’s documentation and continue with this article for an example in ASP.Net MVC.

Putting them Together

Getting Windsor to work in an ASP.Net MVC application is easy if you know what to do. Most things are that way, huh?

For a bare bones integration, just follow these steps:

1. Install ASP.NET MVC 1.0.  The Web Platform Installer is great for this and a ton of other projects.  Try it.  You’ll be glad you did.
2. Open VS 2008,  go to File->New->Project… and select the “ASP.NET MVC Web Application” project template.
3. Select “No” on the proceeding dialog. Do not create a unit test project.
4. Download Castle Windsor 2.0
5. Copy the dlls (Castle.DynamicProxy2, Castle.MicroKernel, Castle.Windsor and Castle.Core) to your solution’s folder or a sub folder.
6. Add them as references to the web project. (Right-click the “References” folder, select “Add Reference…”, select the “Browse” tab and navigate to the dlls to add them.)
7. Add a new XML file to the web project.  Name it “windsor.config” and enter the following:

<?xml version="1.0" encoding="utf-8" ?>
<!--Note: Since this is a web application, all components must have a lifesytle of 'transient' or 'preWebRequest' -->
<configuration>
  <components>
    <!--This is where we could declaratively add components to the Windsor container if we wanted to.-->
  </components>
</configuration>

8. Create an interface IMessageHolder and a class MessageHolder.  (We will use this code to illustrate injecting an instance of MessageHolder into the HomeController.)

public interface IMessageHolder
{
	string GetMessage();
}
 
public class MessageHolder : IMessageHolder
{
	#region IMessageHolder Members
 
	public string GetMessage()
	{
		return "Welcome to ASP.NET MVC using Castle Windsor 2.0!";
	}
 
	#endregion
}

9. Create a controller factory for Windsor:

public class WindsorControllerFactory : DefaultControllerFactory
{
	private readonly IWindsorContainer _container;
 
	public WindsorControllerFactory(IWindsorContainer container)
	{
		_container = container;
	}
 
	protected override IController GetControllerInstance(Type controllerType)
	{
		if (controllerType == null)
		{
			// Force an exception message from the base class.
			// This will be more informative than what we would get otherwise,
			// see: http://stackoverflow.com/questions/719678/custom-controller-factory-dependency-injection-structuremap-problems-with-asp/721313#721313
			return base.GetControllerInstance(controllerType);
		}
		// Exception here ????
		// Check the windsor configuration.
		// Make sure that Windsor can match the component to load.
		return _container.Resolve(controllerType) as IController;
	}
 
	public override void ReleaseController(IController controller)
	{
		_container.Release(controller);
	}
}

10. Open Global.asax.cs and replace it with the following:

public class MvcApplication : HttpApplication
{
	/// <remarks>
	/// This has to be static, because more than one instance
	/// of the HttpApplication can potentially be created.
	/// </remarks>
	private static IWindsorContainer _container;
 
	public static void RegisterRoutes(RouteCollection routes)
	{
		routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 
		routes.MapRoute(
			"Default", // Route name
			"{controller}/{action}/{id}", // URL with parameters
			new {controller = "Home", action = "Index", id = ""} // Parameter defaults
			);
	}
 
	protected void Application_Start()
	{
		RegisterRoutes(RouteTable.Routes);
		InitializeWindsor();
 
		// Setup the MVC framework to use our Windsor controller factory.
		ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(_container));
	}
 
	protected virtual void InitializeWindsor()
	{
		if (_container == null)
		{
			_container = Build("windsor.config");
		}
	}
 
	public static IWindsorContainer Build(string configPath)
	{
		var resource = new FileResource(configPath);
		var interperter = new XmlInterpreter(resource);
		var container = new WindsorContainer(interperter);
 
		// Register controllers
		container.Register(AllTypes
					   .Of<Controller>()
					   .FromAssembly(Assembly.GetExecutingAssembly())
		/* Modify the name with which the component is registered
		See: http://blog.andreloker.de/post/2009/03/28/ASPNET-MVC-with-Windsor-programmatic-controller-registration.aspx */
					   .Configure(c => c.LifeStyle.Transient.Named(c.Implementation.Name.ToLower())));
 
		// Register all other types.
		container.Register(
			Component.For<IMessageHolder>().ImplementedBy<MessageHolder>().LifeStyle.Transient);
 
		return container;
	}
}

11. Add a constructor to the HomeController and give it an IMessageHolder parameter.

    [HandleError]
    public class HomeController : Controller
    {
        private readonly IMessageHolder _holder;
 
        public HomeController(IMessageHolder holder)
        {
            _holder = holder;
        }
 
        public ActionResult Index()
        {
            ViewData["Message"] = _holder.GetMessage();
 
            return View();
        }
 
        public ActionResult About()
        {
            return View();
        }
    }

Since IMessageHolder is registered with Windsor, the container will resolve IMessageHolder to an instance of MessageHolder at run-time. This is called dependency injection because the HomeController dependency is injected through the constructor. Of course, you could do this without an IoC container such as Windsor, but in larger (real world) applications the container will greatly simplify the process of managing dependencies, which means you have a better chance of keeping things loosely coupled and falling into the pit of success.

Notice also that we display the message in Index() to verify that the Windsor container is giving us a valid instance of the type registered for IMessageHolder. This is just a simple way to see the result of what occurred.

12. Run the application and you should see the message on the home page. Click here to download the sample project.

Project Source Code for this post.

I hope that this walk-through helps someone get started with Windsor. It really is an incredible project to learn and if used correctly it will make your programs much better. Have fun with it and Happy Programming!

[System.Data.Linq.Mapping.DatabaseAttribute(Name="MyData")]
public partial class MyDataDataContext : System.Data.Linq.DataContext
{
    // blah ... blah ...
}

public partial class MyDataDataContext
{
    // My additional methods, constructors, etc.
}

As I’ve shown above, this allows you to extend a class without modifying the original code. The additional class definitions just live somewhere else, typically in another file, and the compiler integrates them as needed. That’s great for keeping your code out of the machine generated file, but you still need to be aware of what the machine generated code is doing before you extend it! One thing to check is the default (sqlmetal generated) constructor when you are planning to overload it with your own. In some cases, the default constructor will initialize dependencies, so if you write an overload, make sure it calls the default constructor too:

public partial class MyDataDataContext
{
    public MyDataContext() : this() // We must call the designer generated constructor because it contains initialization code.
    {
        // blah ... blah ...
    }
}

Notice how I used the constructor initialization keyword : this().
From the C# Specification Section 10.10.1

Don't forget to call the default constructor!

Happy Coding!

Upload / Download, used with permission by johntrainor

Somehow I always seem to find edge cases where the abstractions in ASP.Net simply don’t work.  At some point in every project, they break down and I start digging into framework-generated scripts, the DOM, or HTTP request details to figure out what is going on.

Last month, I built an alternative to System.Web.UI.Timer because extending it with client side events would have been much more complicated than a plain JavaScript implementation.  This month, I spent almost an entire day finding out why a FileUpload would sometimes fail to send data back to the server.  The problem arises whenever visibility is changed during an async postback:

The Problem:

Suppose you have a FileUpload inside an UpdatePanel.  It is initially set invisible because the user is supposed to do something before seeing it.  In this example, a button click asynchronously posts back to the server and the server makes the FileUpload visible.  The page would look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<%@ Page Language="C#" %>
<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        // Initially set the FileUpload invivible.
        if (!Page.IsPostBack) { this.fileUploadPanel.Visible = false; }
    }
    protected void showButton_Click(object sender, EventArgs e)
    {
        // User has requested the FileUpload.  Make it visible.
        this.fileUploadPanel.Visible = true;
    }
    protected void submitButton_Click(object sender, EventArgs e)
    {
        // Did the FileUpload send data back to the server?  
        // Print out true or false.
        statusLabel.Text = 
            string.Format("File was found = {0}", fileUpload.HasFile);
    }
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <asp:ScriptManager ID="sm" runat="server" />
    <asp:UpdatePanel ID="updatePanel" runat="server" UpdateMode="Conditional">
        <ContentTemplate>
            <asp:Button ID="showButton" runat="server" Text="Show FileUpload" 
            OnClick="showButton_Click" />
            <br />
            <asp:Panel ID="fileUploadPanel" runat="server">
                <asp:FileUpload ID="fileUpload" runat="server" />
                <asp:Button ID="submitButton" runat="server" Text="Submit" 
                OnClick="submitButton_Click" />
            </asp:Panel>
            <br />
            <asp:Label ID="statusLabel" runat="server" />
        </ContentTemplate>
        <Triggers>
            <asp:AsyncPostBackTrigger ControlID="showButton" />
            <asp:PostBackTrigger ControlID="submitButton" />
        </Triggers>
    </asp:UpdatePanel>
    </form>
</body>
</html>

The problem with this implementation is that the FileUpload fails to send a file on the first submission after it is made visible. Subsequent submissions work fine, but we need a solution that always works.

The First Solution (not great):

Several programmers have noticed that setting the visibility false on the server can cause this problem, so an easy fix is to toggle visibility client side:

1
2

this.fileUploadPanel.Visible = true; // fails
this.fileUploadPanel.Style["display"] = "none"; // works

Using .Style["display"] in lieu of .Visible is fine, but now the server sends the FileUpload to the browser with every request.  In some cases, that is not what you want.  You might want to reduce unnecessary data transfer or you might have client scripts that assume the control does not exist when it is not visible, etc.  This solution is also problematic in that you can apply the fix without knowing why it works.

The Second Solution (much better):

Going back to run our original markup, an examination of the DOM using Firebug or IE Developer Toolbar reveals that there is a difference in the form tag whenever the post fails or succeeds. It was not obvious at first glance, but using WinMerge helped to point it out.

DOM markup before a failed POST  (first attempt):

DOM markup before a successful POST (subsequent attempts):

Apparently, the ASP.Net runtime adds enctype="multipart/form-data" to the form tag whenever it recognizes a FileUpload (or other file input) is being sent to the browser.  Setting the visibility false during initial page load prevents this, and the runtime no longer adds the attribute. 

Using Style["display"] = "none" — our first solution — fixes the problem in a roundabout way: It causes the FileUpload to be sent to the browser on initial page load which in turn causes the runtime to add an enctype. The presence of enctype is really what we need, but since showButton is an AsyncPostBackTrigger, the form tag (being outside the UpdatePanel) is not updated when showButton is clicked. You have to manually add enctype at some point before the FileUpload is made visible on the page.

There are several ways to ensure that this attribute is added to the form.  Anyone reading this far into the post will probably know how to do that, but here is a working example just for closure.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<%@ Page Language="C#" %>
<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        // Initially set the FileUpload invivible.
        if (!Page.IsPostBack) { this.fileUploadPanel.Visible = false; }
    }
    protected void showButton_Click(object sender, EventArgs e)
    {
        // User has requested the FileUpload.  Make it visible.
        this.fileUploadPanel.Visible = true;
    }
    protected void submitButton_Click(object sender, EventArgs e)
    {
        // Did the FileUpload send data back to the server?  
        // Print out true or false.
        statusLabel.Text = 
            string.Format("File was found = {0}", fileUpload.HasFile);
    }
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server" ENCTYPE="MULTIPART/FORM-DATA">
    <asp:ScriptManager ID="sm" runat="server" />
    <asp:UpdatePanel ID="updatePanel" runat="server" UpdateMode="Conditional">
        <ContentTemplate>
            <asp:Button ID="showButton" runat="server" Text="Show FileUpload" 
            OnClick="showButton_Click" />
            <br />
            <asp:Panel ID="fileUploadPanel" runat="server">
                <asp:FileUpload ID="fileUpload" runat="server" />
                <asp:Button ID="submitButton" runat="server" Text="Submit" 
                OnClick="submitButton_Click" />
            </asp:Panel>
            <br />
            <asp:Label ID="statusLabel" runat="server" />
        </ContentTemplate>
        <Triggers>
            <asp:AsyncPostBackTrigger ControlID="showButton" />
            <asp:PostBackTrigger ControlID="submitButton" />
        </Triggers>
    </asp:UpdatePanel>
    </form>
</body>
</html>

Happy Coding!

Let’s say you have a page that needs to post back every x minutes. In my case, I needed to implement an auto-save feature that the client requested. Saving the data would happen server side so I just used a Timer to initiate regular post backs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<%@ Page Language="C#" %>
<script runat="server">
    protected void Timer1_OnTick(object sender, EventArgs e)
    {
        Response.Write("Last Postback: " + DateTime.Now.ToString());
    }
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
        <asp:ScriptManager ID="sm" runat="server" />
        <asp:Timer ID="Timer1" runat="server" 
                OnTick="Timer1_OnTick" Interval="4000" />
    </form>
</body>
</html>

The problem surfaced when they also wanted a client-side prompt to allow or cancel the auto post back. System.Web.UI.Timer does not have any client side events exposed, so I searched the web and asked our friends over at StackOverflow what they would do.

The only response to my post confirmed that the Timer is a bad fit for this situation. I could hack it, but there must be a better way.

Square Peg in a Round Hole

Instead of using a Timer to initiate post backs, I switched to a combination of setTimeout() and __doPostBack(). It’s pure html and JavaScript goodness!

In this example, I added an update panel to demonstrate how __doPostBack() can also be used to create a partial post back (leaving some parts of the page unchanged after the auto post back). That is not necessary, but if you are posting back to the server automatically, an AJAX experience will probably be better for the user.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

<%@ Page Language="C#" %>
<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        if (Page.IsPostBack)
        {
            string time = DateTime.Now.ToString();
            this.insidePanelLabel.Text = "Last Postback: " + time;
            this.outsidePanelLabel.Text = "blah blah"; // Does not show up after partial post back.
        }
    }
</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title></title>
    <script type="text/javascript" language="javascript">
        window.onload = function() {
            // start the auto postback timer.
            setPostbackTimer(8);
        }
        function setPostbackTimer(seconds) {
            window.setTimeout("conditionalPostback()", seconds * 1000);
        }
        function canContinue() {
            return confirm('The page is requesting new data.  Ok or Cancel?');
        }
        function conditionalPostback() {
            if (canContinue()) {
                // User permits the postback. 
                // Do it.
                __doPostBack('UpdatePanel1', '');
            }
            else {
                // User denied the postback. 
                // Reset the timer (they will be prompted again).
                setPostbackTimer(8);
            }
        }
    </script>
</head>
<body>
    <form id="form1" runat="server">
        <asp:ScriptManager ID="sm" runat="server" />
        <asp:UpdatePanel ID="UpdatePanel1" runat="server">
            <ContentTemplate>
                <asp:Label ID="insidePanelLabel" runat="server" 
                    Text="This text will change during auto postbacks."/>
            </ContentTemplate>
        </asp:UpdatePanel>
        <br />
        <asp:Label ID="outsidePanelLabel" runat="server" 
            Text="This text will not change during auto postbacks."/>
    </form>
</body>
</html>

Have you ever tried to make Microsoft controls fit into a situation only to find that plain html and JavaScript are a better fit?

The WebForms model often leads me to over rely on controls and I forget that plain html and JavaScript solutions are available too. Using controls is fine, but think twice if you have to hack them to get what you want. There is probably a better way.

Happy coding.