The stars at night, are big and bright – clap clap clap clap – deep in the heart of Texas!
Hold onto your ten gallon hats, I’m visiting Texas for the first time! I’m very excited to visit the second largest state in the union. ;)
The purpose of my trip is to meet with some developers at Dell doing interesting things and to give a talk there as well.
But since I’ve heard such good things about the vibrant tech community in Austin, I am trying to make the most of my short trip. On Thursday, February 25, I’ll be speaking at Austin .NET User Group meeting at 5:30 PM CST (Location TBD, I’ll post it here when I find out or follow @ehexter on Twitter). So be sure to come by and say hello.
I’m also going to visit my good friends at Headspring as well as Dovetail Software to jabber about technology and see what cool things they’re doing with ASP.NET and ASP.NET MVC.
And of course, a trip to Austin wouldn’t be complete without a night out on the town with Bellware. I expect chaos. ;)
Today I’m pleased to announce the availability of Release Candidate 2 for ASP.NET MVC 2.
After receiving feedback from our last release candidate back in December, we decided it would be prudent to have one more release candidate that incorporated the feedback. You can read the release notes for everything that changed, there’s not a whole lot.
The biggest change in this release was described by Brad Wilson in his blog post on Input Validation vs. Model Validation in ASP.NET MVC. Also included in this release are an assortment of bug fixes and performance improvements.
The window to provide feedback on this release is going to be very short as we are closing in on the RTM. If you want to provide input into this release, please do take the bits for a spin as soon as possible. I’m pretty excited about this release as I can see the end of the tunnel fast approaching. :)
At this point, we’ll only be taking recall class bugs for ASP.NET MVC 2. All other bug reports will be filed against ASP.NET MVC 3. Sometime in the near future, I’ll start sharing some of our planning around that. How exciting!
Oh, and if you missed the link to the Download Details page at the beginning of this post, here it is again.
We also posted the source code and futures assembly on our Codeplex Site.
One question that came up recently during my mid-year review is how am I measuring customer satisfaction with the products that I work on? For example, how can I measurably demonstrate that customers are happy with the work we are doing on ASP.NET MVC and that my team is responding to customer feedback?
Umm, I can’t?
At least not right now in a measurable manner. I don’t have any such metric and I’m not sure how reliable any metric I might come up with will be.
But perhaps that’s simply due to a lack of imagination on my part.
In the past, we’ve tried various unscientific online twitter polls. One thing we did was ask the world for a list of ASP.NET pain points and compile them into one big list. Then at the end of the product cycle, we could show that we were able to address 10% of those pain points.
Personally, I feel that’s a bit contrived, but if it satisfies the muckety mucks, it works for me. ;)
Well actually, I’m not satisfied with that. At least not until I’ve tried to come up with something better. So I started thinking about what are ways to measure this and apart from simply using SurveyMonkey, I’ve sort of hit a wall.
This is where I ask you the question. If you were in my shoes what would you do? How have you quantitatively measured your effectiveness in responding to customer input? I’d love to hear your ideas.
UPDATE 2/4 1:06 AM By the way, I didn’t mean to give the impression that this is the only metric I need to collect. This is just the one I need help with. I think the number of downloads, installations, and clients is a much more important metric. However, some of those numbers are hard to collect with any accuracy. That’s why I think some of these other metrics might be useful as corroborating evidence. At least that’s my theory.
It’s that time of year again when a young man’s thoughts turn to Las Vegas! Yep, it’s another year and another Mix conference (March 15-17, 2010), but this time they’ve changed locations to Mandalay Bay.
It looks like my prediction that the Mix conferences would end at Mix 09 did not pan out. ;)
As I did last year, I’ll be giving two talks at Mix 10 this year, one of them with the irrepressible Scott Hanselman.
Come see and hear about the latest innovations in ASP.NET MVC 2 and the tooling support in Visual Studio 2008 and 2010. We'll introduce you to a range of productivity (and extensibility) enhancements such as template helpers, model validation, and the new “Areas” feature, which enhances the team development of large Web sites. With template helpers you can get your website up and running for any data entity type without having to create UI. With improved server side validation and brand new client side validation support, your business data model can define the behavior of your application automatically. All this and more!
Join Phil Haack and Scott Hanselman for this dynamic and unusual security session. The HaaHa brothers will take turns implementing features on an ASP.NET MVC Web Site. Scott will write a feature, and Phil will exploit it and hack into the system. We’ll analyze and discuss the exploits live on stage and then close them one by one. You’ll learn about XSS, CSRF, JSON Hijacking and more. Is *your* site safe from the Haack?
Lest you think Scott and I have big heads and self inflated egos, I should explain the title of the second talk. Last year Scott and I were supposed to give a talk together at the Norwegian Developer’s Conference, but we were very late in submitting a talk and abstract. As in, we had nothing a week before the conference.
So Rune (the organizer) simply put in the title “The Haacked and Hanselman Show” as a placeholder, and it stuck. This talk will follow in the footsteps of that talk, but in some cases it may be more difficult to give because of security improvements in ASP.NET.
Right now I’m prepping for the talk by attempting to discover a 0 day exploit that I can reveal live as the finale for the talk. Won’t that be fun! ;)
(Yes, I’m kidding you humorless security experts out there)
Anyways, if you’re going to be at Mix, be sure to come by and say hello! Don’t be shy.
Technorati Tags:
mix10,
mix,
las vegas
UPDATE: I’ve updated the original post for editable routes to work in medium trust and not require a full app domain reload like this approach does. I think that approach may supersede this approach until I learn otherwise. :)
Yesterday I wrote about a technique using dynamic compilation to allow editing routes after you’ve deployed an application without having to manually recompile your application.
I made use of a FileSystemWatcher to monitor a Config directory and dynamically recompiled code when the code file changed. This has one advantage over using the App_Code directory in that the whole App Domain doesn’t need to get recycled when you make changes to your routes.
Today, my co-worker David Ebbo (who’s a master at ASP.NET Build and Compilation system) pointed out one gaping flaw with my approach. It doesn’t work in Medium Trust because the FileSystemWatcher class demands full trust. Doh!
For many business systems, that may not be a concern. But for my blog engine, it’s a huge concern. There are workarounds to the FileSystemWatcher issues, but I decided to take the easy way out and use the App_Code directory approach, since it handles all that crufty logic for watching the file system for me.
In this case, I simply added a new folder named App_Code to my project and copied Routes.cs to that folder.
I then added a new method to RouteRegistrationExtensions. (Note that the actual code has some null reference checking which I omitted here.)
public static void RegisterAppCodeRoutes(this RouteCollection routes) {
var type = BuildManager.GetType("Routes", false/*throwOnError*/);
var registrar = Activator.CreateInstance(type) as IRouteRegistrar;
registrar.RegisterRoutes(RouteTable.Routes);
}
So instead of the method I wrote in my previous post, I call this method. The nice thing here is that this method doesn’t have to worry about attaching a FileSystemWatcher or handling events and reloading routes.
Any time the Routes.cs file is changed, the entire App Domain is restarted and Application_Start is called again.
I want to also point out that a long while ago, I showed a different approach for editable routes using IronRuby that you might be interested in.
You can download the sample project here which includes both methods for doing editable routes.
UPDATE: I’ve updated this to work in Medium Trust without having to restart the entire App Domain using a technique proposed by my co-worker David Ebbo. I am no longer using the FileSystemWatcher which had problems in Medium Trust
In general, once you deploy your ASP.NET MVC application, you can’t change the routes for your application without recompiling the application and redeploying the assembly where your routes are defined.
This is partly by design as routes are generally considered application code, and should have associated unit tests to verify that the routes are correct. A misconfigured route could seriously tank your application.
Having said that, there are many situations in which the ability to change an application’s routes without having to recompile the application comes in very handy. This is the situation I find myself in as I build a blog engine where the folks who will install may want to tweak the routes without having to recompile the blog’s source code.
In this post, I’ll demonstrate an approach that’ll allow you to define your routes in a content file as code (no XML here!) which you deploy with your application as in the screenshot.
In my implementation, you need to place the routes in a Config folder in your web root. Note that I used Visual Studio’s Properties dialog to mark the file’s Build Action as “Content” so that it’s not compiled into my application.
What this means is that the code in the Routes.cs file is not compiled with the application. Instead, we will dynamically compile it. First, let’s look at the contents of that file. It shouldn’t be too surprising.
using System.Web.Mvc;
using System.Web.Routing;
using EditableRoutesWeb;
public class Routes : IRouteRegistrar
{
public void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
}
}
One thing you’ll notice is that this class implements an interface named IRouteRegistrar. This is an interface I created and added to my web application (though it could be defined in another assembly).
The code in Global.asax.cs for this application simply calls an extension method I wrote.
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RouteTable.Routes.RegisterRoutes("~/Config/Routes.cs");
}
It’s the code in this extension method where the real magic happens.
Before I show the code, there are two concepts at work here that make this work. The first is using the BuildManager to dynamically create an assembly from the Routes.cs file. From that assembly, we can create an instance of the type Routes and cast it to IRouteHandler.
var assembly = BuildManager.GetCompiledAssembly("~/Config/Routes.cs");
var registrar = assembly.CreateInstance("Routes") as IRouteRegistrar;
Once we have an instance of a route registrar, we can call RegisterRoutes on that instance.
The second concept is being able to get notification when the Routes.cs file changes. The clever trick that David told me about is using the ASP.NET Cache object to do that. When you add an item to the cache, you can give it a cache dependency pointing to a file and a method to call when the cache is invalidated.
With those two pieces, we can add a cache dependency pointing to Routes.cs and a callback method which will reload the routes when Routes.cs is changed.
Here’s the full listing for RouteRegistrationExtensions.
public static class RouteRegistrationExtensions
{
public static void RegisterRoutes(this RouteCollection routes,
string virtualPath)
{
ConfigFileChangeNotifier.Listen(virtualPath,
vp => routes.ReloadRoutes(vp));
}
static void ReloadRoutes(this RouteCollection routes, string virtualPath)
{
var assembly = BuildManager.GetCompiledAssembly(virtualPath);
var registrar = assembly.CreateInstance("Routes") as IRouteRegistrar;
using(routes.GetWriteLock())
{
routes.Clear();
registrar.RegisterRoutes(routes);
}
}
}
This uses a class called ConfigFileChangeNotifier which is based on some code David wrote for Dynamic Data.
public class ConfigFileChangeNotifier
{
private ConfigFileChangeNotifier(Action<string> changeCallback)
: this(HostingEnvironment.VirtualPathProvider, changeCallback)
{
}
private ConfigFileChangeNotifier(VirtualPathProvider vpp,
Action<string> changeCallback) {
_vpp = vpp;
_changeCallback = changeCallback;
}
VirtualPathProvider _vpp;
Action<string> _changeCallback;
// When the file at the given path changes,
// we'll call the supplied action.
public static void Listen(string virtualPath, Action<string> action) {
var notifier = new ConfigFileChangeNotifier(action);
notifier.ListenForChanges(virtualPath);
}
void ListenForChanges(string virtualPath) {
// Get a CacheDependency from the BuildProvider,
// so that we know anytime something changes
var virtualPathDependencies = new List<string>();
virtualPathDependencies.Add(virtualPath);
CacheDependency cacheDependency = _vpp.GetCacheDependency(
virtualPath, virtualPathDependencies, DateTime.UtcNow);
HttpRuntime.Cache.Insert(virtualPath /*key*/,
virtualPath /*value*/,
cacheDependency,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.NotRemovable,
new CacheItemRemovedCallback(OnConfigFileChanged));
}
void OnConfigFileChanged(string key, object value,
CacheItemRemovedReason reason) {
// We only care about dependency changes
if (reason != CacheItemRemovedReason.DependencyChanged)
return;
_changeCallback(key);
// Need to listen for the next change
ListenForChanges(key);
}
}
With this in place, you can now change routes within the Routes.cs file in the Config directory after you’ve deployed the application. Note that technically, a recompilation is happening, but it’s happening dynamically at runtime when the file changes and there’s no need to restart your entire App Domain, which is one benefit of this approach over using the code in App_Code.
If you want to try this code out, you can download a sample project here. The sample app is compiled against ASP.NET MVC 2 RC, but the same principles and code can be used with an ASP.NET MVC 1.0 application. In fact, it can also be used in an ASP.NET 4 Web Forms application since we now support page routing.
Note, if you want to see the old version of this code, I’ve archived it here.
This is the second job posting in two days for positions on the ASP.NET team, how exciting! This one is a developer position for upcoming graduates.
Before I continue, I need to fulfill a promise to a co-worker to include a barely relevant stock photograph in this blog post.
Good, with that out of the way, allow me to continue.
If you are in college or grad school, graduating in 2010, and are looking for a great job writing code for ASP.NET, we have a position available! Send me your resume and I’ll forward it along to the proper people.
My email address is philha at (my company).com where (my company) is Microsoft. If you can’t figure out based on that where to email your resume, you probably shouldn’t bother applying ;)
Once again, this is for college or graduate school students graduating in 2010. If you’re not an upcoming graduate, consider we also have a QA position available.
I look forward to seeing you roam the halls of building 42.
The ASP.NET Team is still looking for that QA person out there who shares our passion for technology and improving the means by which software is made.
Keep in mind that the QA position on our team is not someone who mindlessly follows a script hoping by sheer random luck to find bugs. Oh no no no my friends.
This is considered a software development position in which you will be responsible for improving the processes and tools we have in place for ensuring quality software. You’d be involved in improving the quality of all phases of product development as a valued member of a feature crew. Think broadly about the idea of software quality. Your role is to question whether we’re building the right product as much as it is to test the product once it is built.
Matt Osborn, a member of the ASP.NET MVC feature crew has a description of the position.
That’s right you read the title right the ASP.NET QA team is once again hosting ninja try outs. We are looking for someone who is able to help evolve the team processes, improve our tooling, and join us in the trenches as we test one of the best technologies out there. Overall the team is responsible for ASP.NET WebForms, ASP.NET MVC, Microsoft AJAX, and a whole slew of other technologies. Our technologies can be found in numerous large scale web sites such as MySpace.com, Dell.com andDeals.Woot.com.
Once again we would like to find someone that shares our passion for our technology and our trade and someone that has spent sometime in the trenches. So if this sounds like something you’re interested in polish your nun chucks, practice your disappearing skills, and slice your way through our job posting. In the meantime while your sword is out for sharpening send Mark Berryman (one of our managers) an email.
PS: If you listen to the Coding QA podcast you can get a good feel for what it is like being the frontline testing ninjas for ASP.NET. We had a great turn out last time and please feel free submit your resume again it can’t hurt.
Keep in mind we’re not looking for “test” ninjas as in “sample” ninjas. We’re looking for the real deal, brimming with throwing stars of bug finding. Ok, the analogy breaks down a bit there. But you get the picture.
And before I forget, here’s the direct link to the job description on the Microsoft careers site.
This blog is experiencing technical difficulties. Do not adjust your browser.
Hi there. If you’ve tried to visit this blog recently you might have noticed it’s been down a lot in the last two days. My apologies for that, but hopefully you found what you needed via various online web caches.
I’ve been dogfooding the latest version of Subtext and as CodingHorror points out, dogfood tastes bad.
I’ve done a lot of testing on my local box, but there are a class of bugs that I’m only going to find on a high traffic real site, and boy have I found them!
Some of them might be peculiar to my specific data or environment, but others were due to assumptions I made that were wrong. For example, if you use ThreadPool.QueueUserWorkItem to launch a task, and that task throws an unhandled exception, that can bring your entire App Domain down. Keep that in mind if you think to use that method for a fire-and-forget style task.
In any case, the point of this post is to say that we’re not going to release the next version of Subtext until it’s rock solid. My blog going down occasionally is the cost I’m incurring in order to make sure the next version of Subtext is a beast that won’t quit.
Technorati Tags:
Subtext,
Dogfooding
Note: This describes the behavior of ASP.NET MVC 2 as of the release candidate. It’s possible things might change for the RTM.
When using areas in ASP.NET MVC 2, a common problem you might encounter is this exception message.
The controller name 'Home' is ambiguous between the following types:
AreasDemoWeb.Controllers.HomeController
AreasDemoWeb.Areas.Blogs.Controllers.HomeController
This message is telling you that the controller factory found two types that match the route data for the current request. Typically this happens when you have a controller of the same name in an area and in the main project.
For example, in the screenshot below, notice that we have a HomeController in the main Controllers folder as well as in the Blogs area.
If you make a request for the area such as /Blogs/Home, you’ll find that everything works hunky-dory. However, if you make a request for the root HomeController, such as /Home, you’ll get the ambiguous controller exception.
Why is that?
When you register routes for an area, they get a namespace associated with each route. That ensures that only controllers within the namespace associated with that area can fulfill the request. Thus the request that matches an area will have that namespace and the namespace is used to disambiguate controllers.
But by default, the routes in the main application don’t have a namespace associated with them. That means the controller factory will scan all types looking for a match, and in this case finding two types which match the controller name “Home”.
The Fix
There are two very simple workarounds. The simplest falls in the “If it hurts, stop doing that” camp which is to simply avoid naming two controllers the same name.
For many situations, this is not a satisfactory answer. The other workaround, as you might guess from my explanation of why this happens, is to give the route in the main application a specific namespace. Here’s an example of the default route in Global.asax.cs which has the fix.
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL
new { controller = "Home", action = "Index", id = "" }, // Defaults
new[]{"AreasDemoWeb.Controllers"} // Namespaces
);
}
In the code above, I added a fourth parameter which is an array of namespaces. The controllers for my project live in a namespace called AreasDemoWeb.Controllers.
Follow Up
In a follow-up post, I’ll walk through more details about areas and how namespaces play into routing and controller lookup. For now, I hope this gets you unstuck if you’ve run into this problem before.