This is the third post in a series related
to build and deployment considerations as I’ve been exploring MVC Portable Areas: #1 – Using Web Application Project
to build portable areas #2 – Conventions for deploying portable area static files #3 – Portable area static files as embedded resources In the last post, I walked through a convention for managing static files. In this post I’ll discuss another approach
to manage static files (e.g., images, css, js, etc.). With this approach, you *also* compile the static files as embedded resources into the assembly similar
to the *.aspx pages. Once again, you can set this
to happen automatically by simply modifying your *.csproj file
to include the desired extensions so you don’t have
to remember every time you add a file: 1: <Target Name="BeforeBuild">
2: <ItemGroup>
3: <EmbeddedResource Include="**\*.aspx;**\*.ascx;**\*.gif;**\*.css;**\*.js" />
4: </ItemGroup>
5: </Target>
We now need a reliable way
to serve up these static files that are embedded in the assembly. There are a couple of ways
to do this but one way is
to simply create a Resource controller whose job is dedicated
to doing this.
1: public class ResourceController : Controller
2: {
3: public ActionResult Index(string resourceName)
4: {
5: var contentType = GetContentType(resourceName);
6: var resourceStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName);
7:
8: return this.File(resourceStream, contentType);
9: return View();
10: }
11:
12: private static
string GetContentType(string resourceName)
13: {
14: var extention = resourceName.Substring(resourceName.LastIndexOf('.')).ToLower();
15: switch (extention)
16: {
17: case ".gif":
18: return "image/gif";
19: case ".js":
20: return "text/javascript";
21: case ".css":
22: return "text/css";
23: default:
24: return "text/html";
25: }
26: }
27: }
In order
to use this controller, we need
to make sure we’ve registered the route in our portable area registration (shown in lines 5-6):
1: public class WidgetAreaRegistration : PortableAreaRegistration
2: {
3: public override void RegisterArea(System.Web.Mvc.AreaRegistrationContext context, IApplicationBus bus)
4: {
5: context.MapRoute("ResourceRoute", "widget1/resource/{resourceName}",
6: new { controller = "Resource", action = "Index" });
7:
8: context.MapRoute("Widget1", "widget1/{controller}/{action}", new
9: {
10: controller = "Home",
11: action = "Index"
12: });
13:
14: RegisterTheViewsInTheEmbeddedViewEngine(GetType());
15: }
16:
17: public override
string AreaName
18: {
19: get { return "Widget1"; }
20: }
21: }
In my previous post, we relied on a custom Url helper method
to find the actual physical path
to the static file like this:
1: <img src="<%: Url.AreaContent("/images/arrow.gif") %>" /> Hello World!
However, since we are now embedding the files inside the assembly, we no longer have
to worry about the physical path. We can change this line of code
to this:
1: <img src="<%: Url.Resource("Widget1.images.arrow.gif") %>" /> Hello World!
Note that I had
to fully quality the resource name (with namespace and physical location) since that is how .NET assemblies store embedded resources. I also created my own Url helper method called Resource which looks like this:
1: public static
string Resource(this UrlHelper urlHelper,
string resourceName)
2: {
3: var areaName = (string)urlHelper.RequestContext.RouteData.DataTokens["area"];
4: return urlHelper.Action("Index", "Resource", new { resourceName = resourceName, area = areaName });
5: }
This method gives us the convenience of not having
to know how
to construct the URL – but just allowing us
to refer
to the resource name. The resulting html for the image tag is:
1: <img src="/widget1/resource/Widget1.images.arrow.gif" />
so we can always request any image from the browser directly. This is almost analogous
to the WebResource.axd file but for MVC. What is interesting though is that we can encapsulate each one of these so that each area can have it’s own set of resources and they are easily distinguished because the area name is the first segment of the route. This makes me wonder if something like this ResourceController should be baked into portable areas itself.
I’m definitely interested in anyone has any opinions on it or have taken alternative approaches.
