An open letter to the azure team

I don’t blog much anymore, but this seems a good topic given the past couple of weeks.  First off, I am liking azure a lot – and that’s a huge climb from just 6 months ago. I’m playing around with some of the new features of azure and this is absolutely great. I also believe there are some core competencies that are lacking.  As azure grows, these core competencies will become more important to adoption.

I am working on a project that could be a good fit for azure and it’s focused enough that the billing doubts I see here are not show-stoppers, but I can see where these could be hurdles for any project. 

General Comments:

1. Operational Architecture: Ok – so azure is more technically advanced that amazon.  We get it, now get over it.  That message is sprawled throughout your documentation and comes across as amateurish after reading it the fifteenth time. The solution – message that in one area documenting it thoroughly.  When you feel the need to call it out in some deeper document, reference it instead of regurgitating it.
2. Developer Communication: So much falls under this.  You need a community driver like a Scott Hanselman, Phil Haack or Glenn Block saying “look how easy it is to do [x]” and then showing it in 15 lines or less.  There are some msdn blog posts that do this, but good authors tend to be augered-in on what they are doing on the team rather than relating to the customer.  And too much of the documentation feels like it’s written for folks on an internal microsoft email group.  Your customers don’t have that access path and, as such, it marginalizes the quality. The solution – get a community focused team member working on the developer experience across the board acting as both a writer and a director by pointing people to other content. It gives end-users a go-to guy.  Given the breadth of azure, you probably need more than one.
3. Off-site Integration Story – this story is great and the tools are slick.  Now make them more understandable and accessible to your audience.  Show us real life scenarios and build their stories so we can put them to use.
4. Queing and Storage Stories – same thing as the offsite story.  The capabilities are awesome, communicate them better.
5. Onboarding- how can I mention this without saying “appharbor” at least once?  My three month demo account keeps getting turned off and the story that comes back doesn’t make sense. It’s annoying.  I suspect it falls to my “get billing sorted out” point below and more importantly it casts a doubt on what my real monthly bill will be. That’s not a doubt you want living in your customer’s minds – it will kill adoption faster than anything else listed here.  Appharbor is still easier on initial startup, but it’s following points that would have me more concerned.

Get billing sorted out:

I’ve separated this topic out because it is in my estimation the most important one here. 

• Is azure boutique priced or usage priced? The difference between the two is that usage pricing is fully traceable and the algorithm is public.  If one or more of these conditions is not true, you are boutique priced.  Azure tries to ride both and in that respect your message is schizophrenic.  This is a hard call, and at its heart is not a technical one. It is also one of the most difficult calls to make because you are exposing yourself to modeling. For that reason alone, communicating this can be harder to do internally than externally.  Somone high up needs to step up, back the call and communicate it to everyone.
• Give me the tools to understand my bill.  At the end of the day, your customers must be able to understand their expenditures on azure.  We also need to model it given our understanding of our solution, our clients and how we see the product growing.  These are things the azure team will never be able to internalize so give us the tools to do this on our own. 

I suspect that last case would take six months to iron out, but it needs to be done. Hopefully the azure team is already working on it.

-Steve

Using MEF and Autofac to discretely control Ioc Wireup

Autofac is currently my favorite IoC container with support for constructor depedency injection with things like factories with Func<T>, Func<T, params> and Lazy<T> among others. Autofac is very clean and concise with plenty of hooks throughout the lifecycle. Using Lazy<T> effectively declares that I want an instance of T that is not instantiated until I first use it. The Lazy<T> type is borrowed straight from MEF. I’m leaving a lot out here in my summary – in short it’s a great container. Whether or not it’s your container of choice, take a listen to Nikolaus Blumhardt discuss Autofac 2, MEF and other topics on “Talking Shop Down Under”. It’s a great discussion about Autofac in particular and DI in a broader sense.

But let’s take this MEF thing a little further. I should note that I am using MEF Preview 9 on .Net 3.51 from MvcContrib. This approach works the same on .Net 4.0 as well (without the need to download MEF of course).

Autofac has it’s own scanning capability that puts you closer to convention-based registration, while this approach gives you a different style of control.

Creating a Common Registrar Interface

Autofac uses the notion of a ContainerBuilder that takes our fluent configuration and roles it into a container. In that light, we’ll create a generic interface that allows us to register components via an instance of a ContainerBuilder like so:

public interface IIocRegistrar
{
/// <summary>
/// Accepts a container builder to configure with mappings
/// </summary>
/// <param name="builder">autofac container builder</param>
void RegisterComponents(ContainerBuilder builder);
}

Given this interface, we can write a concrete implementation that takes wires up our builder according to how we want things configured like so:

public class IocRegistrar : IIocRegistrar
{
#region IIocRegistrar Members

public void RegisterComponents(ContainerBuilder builder)
{
builder.RegisterType<FooModelCreator>().Named<IModelCreator>(“Foo”));
builder.RegisterType<BarModelCreator>().Named<IModelCreator>(“Bar”));
}

#endregion
}

So, that’s great, we can call that and get our container built, but what if we have components that span multiple namespaces or assemblies? Do we really want a single registrar tying all these things together?

Instead, let’s decorate that same class with the MEF ExportAttribute like so:

[Export(typeof(IIocRegistrar))]
public class IocRegistrar : IIocRegistrar
{
#region IIocRegistrar Members

public void RegisterComponents(ContainerBuilder builder)
{
builder.RegisterType<SalesRepModelCreator>().Named<IModelCreator>(“Foo”));
builder.RegisterType<AdminModelCreator>().Named<IModelCreator>(“Bar”));
}

#endregion
}

MEF in the Bloodstream - or - seeking out all registrars at runtime

This is MEF in its simplest form – we’re categorizing our Export as a type that we will use to discover at runtime. If we want to segment our containers, we can add a ‘contractName’ parameter to further declare groupings of registrars and pull them back by name. This opens up a lot of possibilities, but we’ll focus on the simplest case here.

When building up our container – we may do this in a central resolver if using ServiceLocation, or this can be done more generically on app startup and integrate it with something like Mvc’s resolver wireup. Here we’ll use the DirectoryCatalog to go after everything in the bin directory to get our wireups. If we wanted to go after registrars of a particular name, we can change the GetExportedValues call to take care of this.

var moduleBuilder = new ContainerBuilder();

var directoryCatalog = new DirectoryCatalog(GetAssemblyLocation());

// create a container that we use to discover and compose
var container = new CompositionContainer(directoryCatalog);

foreach (var registrar in container.GetExportedValues<IIocRegistrar>())
registrar.RegisterComponents(moduleBuilder);

We have now told the application to search out all IIocRegistrar exports and build up the container builder accordingly.

Resolving Instances with Autofac

From here on out, everything is the same. No traces of MEF, just Autofac container behavior as usual. Registered types can be resolved from the container created by the builder. Using Service Location to demonstrate the behavior looks like this:

var container = moduleBuilder.Build();

var modelCreator = container.Resolve<IModelCreator>("Foo");

That’s All Folks!

So there you have it. You can now have Ioc registration defined at whatever granularity you choose and even have it occur across assembly layers in your application. While Autofac supports the use of Xml configuration, the ability to test our wireup in small consumable pieces and avoid centralized registrars that reach across many namespaces keeps things light and simple.

The DerivedTypeModelBinder in MvcContrib

This content has been moved to the MvcContrib Codeplex site. Please refer to that link for the latest, most current documentation.

ValidationAttribute Test Harness updated on Codeplex

Ahead of tomorrow’s 12:00-1:00 Central Brown Bag / Show and Tell over at C4MVC, I made a few changes for the ValidationAttribute Test Harness based on feedback. The changes focus on two areas:

1. Discoverability: Do we really need to identify all the custom validators on startup? No – MEF handles this very well thank you.
2. Runtime Statistics: Can we get a picture of what was done on a given run?

These changes were added to software, and the mechanism of calling the Analyze method (1) gives the ability to extend other scanning options and (2) provides for a platform where the MEF discovery results can be reused over multiple calls.

   1: var analyzer = new ValidationAnalyzer();

   2: var results = analyzer.AnalyzeAssembly(typeof (ChangePasswordModel).Assembly, true);

   3:  

   4: Console.WriteLine(results.AnalysisSummary());

   5:             

   6: Assert.That(results.Valid, Is.EqualTo(true), results.CompileErrorMessage());

This is going to be a fun call. We’ll focus on the latest tidbits about how ValidationAttributes are integrated with MVC, a set of ‘gotchas’ that the test harness keeps you clear of and more.

Introducing the ValidationAttribute Test Harness on Codeplex

***************************

*** Update: for the latest on how to use the ValidationAttribute Test Harness, check out my latest post in this series...

***************************

This article is an introduction to the ValidationAttribute Test Harness project on Codeplex. This project exists to fill a testing void and maintain quality on ValidationAttributes. Our of the box – the ValidationAttribute Test Harness monitors the declaration of error messages and validates their runtime state. This article briefly discusses the nature of ValidationAttributes, the testing issues around the resource approach and how this new CodePlex project addresses the shortcomings.

The standard thinking around testing ValidationAttribute derived classes is that these are not individually testable – but rather relegated to automated ui testing or exploratory testing. While a certain portion of that is true – we cannot fully recreate the framework that interacts with these properties - we can provide a contextual harness that allows us to test the declarations to ensure that the declarations map to their intended targets (and that intended targets are who they say they are).

Purpose 1: Verifying Properly Localized ValidationAttributes at their Attribution Site

When looking at the ValidationAttribute, you quickly notice three properties that give access to declaring the error message raised when the rule is violated. These three are:

• string ErrorMessage
• string ErrorMessageResourceName
• Type ErrorMessageResourceType

It becomes apparent that there are quality issues, especially when it comes to localization.

1. Setting a string on ErrorMessage means the error message is not localizable.
2. The ErrorMessageResourceName is meant to point to a static public property on a resource class – but this is a magic string.
3. Both the Type and Name must be set for resourced error messages to be identified.
4. There are a number of combination-style errors that can arise.
5. The errors that are thrown are obscure and difficult to locate – with details buried deep in the exceptions.

We need a mechanism to test for these scenarios and provide a list of readable errors that lead us directly to the source and allow us to triage them quickly.

Purpose 2: Verifying Custom Attribute Annotations

Custom-defined Attributes, aside from the standard set, are as wide open as we like them to be. They are especially useful when declaring relationships between data. The ASPNET MVC framework generates one out of the box in it’s application template called PropertiesMustMatchAttribute. The attribute is placed at the class level where it declares two properties (via strings) to declare that the two properties are equal which is useful on the model when resetting a password.

This has all the same problems we see with magic strings -

1. What if the declaration is wrong
2. What if one of the property names change. The stringified name won’t be changed with it automatically.
3. What if only one or none of the property names is declared?

Waiting for runtime to discover these kinds of errors is unacceptable.

Using the ValidationAttribute Test Harness to Raise the Quality Bar

Out of the box, the ValidationAttribute Test Harness will take a look at all the ValidationAttribute attributions in your project and verify the configuration of the Error Message related attributes. It will also pull together error information into one concise list that can be easily triaged.

   1: var analyzer = new ValidationAssemblyAnalyzer(typeof(ChangePasswordModel).Assembly, true);

   2: Assert.That(analyzer.ValidationErrorInfoList.Count, Is.EqualTo(0), analyzer.CompileErrorMessage());

The analyzer can also take lists of custom validators so we can provide customized tests based on the attribute type like so:

   1: var analyzer = new ValidationAssemblyAnalyzer(typeof (ResourcedValidationAssemblyAnalyzerTests).Assembly, true, 

   2:                           null,

   3:                           new[] {new PropertiesMustMatchValidator()});

   4:  

   5: Assert.That(analyzer.ValidationErrorInfoList.Count, Is.EqualTo(0), analyzer.CompileErrorMessage());

… this is a great place for MEF, but I’ve held off to avoid dependencies on this initial release. If people just copy the code into their projects, great. If they tend to grab the assembly as a dependency in their unit test project, then it makes more sense. For net4.0, MEF is a no-brainer but we’ll cross that bridge when we get to it. …

Note that the Analyzer takes two enumerable lists – one for member-specific attribute validators and one for class-specific attribute validators. These are denoted by the interface they are derived from: ICustomValidationByTypeAnalyzer or ICustomValidationByMemberAnalyzer.

Understanding How To Write Custom Validators

Writing the custom validators is straightforward and simple. Just implement the ICustomValidator interface on your validator according to the attribute site target. From there, you declare:

1. The type of the attribute that you are testing.
2. The actual test using the contextual information about the attribution site.

And there you have it. Check out the code below to see the custom validator in detail. It’s not fully fleshed out, but provides a good boilerplate as such. Now each time you run your unit tests, your models will be validated and you won’t have to

   1: // since the matching attribute only applies at the class level, we'll use the ByTypeAnalyzer variant

   2: public class PropertiesMustMatchValidator : ICustomValidationByTypeAnalyzer 

   3: {

   4:     #region ICustomValidationByTypeAnalyzer Members

   5:  

   6:     /// <summary>

   7:     /// Here we'll test that the property exists on the object according to our criteria

   8:     /// </summary>

   9:     /// <param name="candidateType">attributed class</param>

  10:     /// <param name="propertyName">property name to look for</param>

  11:     /// <returns></returns>

  12:     private bool PublicPropertyExists(Type candidateType, string propertyName)

  13:     {

  14:         return candidateType.GetProperty(propertyName, BindingFlags.GetProperty | BindingFlags.Public | BindingFlags.Instance) != null;

  15:     }

  16:  

  17:     /// <summary>

  18:     /// Responsible for raising errors according to the tests being performed on

  19:     /// the PropertiesMustMatch validator

  20:     /// </summary>

  21:     /// <param name="candidateType">candidate class type information</param>

  22:     /// <param name="validationAttribute">the validation attribute instance that is being tested</param>

  23:     /// <param name="enforceResourceMode">whether to enforce valid resourcing</param>

  24:     /// <returns>list of error error information</returns>

  25:     public IEnumerable<CustomValidationInfo> Validate(Type candidateType, ValidationAttribute validationAttribute, bool enforceResourceMode)

  26:     {

  27:         var list = new List<CustomValidationInfo>();

  28:         var matchAttribute = validationAttribute as PropertiesMustMatchAttribute;

  29:  

  30:         if (!String.IsNullOrEmpty(matchAttribute.OriginalProperty) &&

  31:             !String.IsNullOrEmpty(matchAttribute.ConfirmProperty))

  32:         {

  33:             if( ! PublicPropertyExists(candidateType, matchAttribute.OriginalProperty))

  34:                 list.Add(new CustomValidationInfo(ValidationStatus.DeclarationError, string.Format(CultureInfo.InvariantCulture, "OriginalProperty named '{0}' does not exist on the object", matchAttribute.OriginalProperty)));

  35:  

  36:             if( ! PublicPropertyExists(candidateType, matchAttribute.ConfirmProperty))

  37:                 list.Add(new CustomValidationInfo(ValidationStatus.DeclarationError, string.Format(CultureInfo.InvariantCulture, "ConfirmProperty named '{0}' does not exist on the object", matchAttribute.ConfirmProperty)));

  38:  

  39:             // more tests could be added here - validating type, other required attribute declarations, etc

  40:         }

  41:         else

  42:             list.Add(new CustomValidationInfo(ValidationStatus.DeclarationError,

  43:                                               "Original Property and/or ConfirmPropert is not set"));

  44:  

  45:         return list;

  46:  

  47:     }

  48:  

  49:     /// <summary>

  50:     /// the attribute type that this validator is testing

  51:     /// </summary>

  52:     /// <returns>Type info on the targeted attribute</returns>

  53:     public Type TargetType()

  54:     {

  55:         return typeof (PropertiesMustMatchAttribute);

  56:     }

  57:  

  58:     #endregion

  59: }

Summary

And there you have it. Check out the code above to see the custom validator in detail. It’s not fully fleshed out, but provides a good boilerplate as such. Now each time you run your unit tests, your models will be validated and you won’t have to ‘wait until runtime’ to discover the quality of your model attributions.

Localizing LabelFor in ASP.NET MVC 2

I started the weekend spelunking ModelBinder with Reflector and started toying with the front-end html helpers. The ASP.NET MVC 2 builds on the MVCContrib FluentHtml implementation and includes some fantastic features for eliminating magic strings in your html. If you are not familiar with the implementation, this piece of code summarizes the Html.LabelFor implementation. For a broader view of these modifications, check out Scott Gu's blog series on the broader functionality.

   1: <div class="editor-label">

   2:    <%=Html.LabelFor(m => m.LastName)%

   3: </div>

If you refactor your model implementation, the front-end html gets refactored along with it. The default implementation relies on marking up the model using DisplayNameAttribute to resolve a user-readable name.

   1: [Required]

   2: [DisplayName("Last Name")]

   3: [StringLength(64)]

   4: public string LastName { get; set; }

The problem with Attributes is that there is no reasonable way I’ve seen to create a DisplayName attribute style variant that is resource-aware. This is primarily due to constraints on Attributes in the form of generic and runtime type constraints. In short, there is no way to create a flexible approach with (1) no magic strings involved and (2) a format convention that can vary across different MVC Areas.

After looking over the first approach, I looked at creating a new LabelFor extension method. I had two driving criteria in creating the solution - (1) avoid any magic strings in the views and (2) allow for easy and flexible variation of naming rules associated with resource classes.

I like the result as the core workings are very testable and the flexibility is straight-forward.

The first part of the solution includes the LabelFor extension. You’ll notice it mirrors the LabelFor(Expression<…>) implementation by adding the ResourcePropertyResolver<T> implementation. In order to grab the associated metadata, I am relying on the same ModelMetadata calls that the existing LabelFor implementation uses. It then relies on the existing Label(string) implementation to generate the output.

   1: /// <summary>

   2: /// Our own set of custom label extensions

   3: /// </summary>

   4: public static class CustomLabelExtensions

   5: {

   6:     /// <summary>

   7:     /// Returns an HMTL label element with the content resolved for the given propety according to

   8:     /// the format specified in the parameters

   9:     /// </summary>

  10:     /// <typeparam name="TModel">The model typically inferred from the prage</typeparam>

  11:     /// <typeparam name="TValue">Value type inferred from expression</typeparam>

  12:     /// <typeparam name="TResourceType">Resource type used as the string resolution target</typeparam>

  13:     /// <param name="html">extension method parameter</param>

  14:     /// <param name="resourcePropertyResolver">resource resolver that indicates the resolution target 

  15:     /// and format strings</param>

  16:     /// <param name="expression">expression tree intended to point at the property being named</param>

  17:     /// <returns>localized, resolved label for the property</returns>

  18:     public static MvcHtmlString LabelFor<TModel, TValue, TResourceType>(this HtmlHelper<TModel> html, ResourcePropertyResolver<TResourceType> resourcePropertyResolver, Expression<Func<TModel, TValue>> expression)

  19:     {

  20:         var metaData = ModelMetadata.FromLambdaExpression(expression, html.ViewData);

  21:  

  22:         var resourcePropertyName = string.Format(CultureInfo.InvariantCulture, resourcePropertyResolver.ResourcePropertyFormatPolicy,

  23:                                                  metaData.ContainerType.Name, metaData.PropertyName);

  24:  

  25:         return html.Label(resourcePropertyResolver.GetResourceValue(resourcePropertyName));

  26:     }

  27: }

The next part is a default implementation of ResourcePropertyResolver. Starting at the top, this is a generic class requires the type of your resource class. A resource class is effectively any class that has static properties – the code-gen component of Visual Studio takes the resource table and implements it as a plain old class. Remember that the code generator property defaults to internal types – called out on the Custom Tool property. You can make these all public types by changing the Custom Tool property to PublicResXFileCodeGenerator.

First off, a static readonly type is resolved once for the class to avoid multipel typeof(…) resolutions – an efficiency move here. Next, a couple of string formatting properties. The first calls out the naming policy for properties on the resource class. The default value is ‘[class name]_[property name]’. The second format calls out the value that should be returned when a matching value is not found. Note that both of these are overridable which I will demonstrate in a moment.

Finally, the GetResourceValue method does the heavy lifting of locating the property in the table and formatting output accordingly.

   1: /// <summary>

   2: /// Implements access of the actual resource class and the associated

   3: /// formatting rules for property names and unresolved resource values

   4: /// </summary>

   5: /// <typeparam name="TResourceType">resource class</typeparam>

   6: public class ResourcePropertyResolver<TResourceType>

   7: {

   8:     private static readonly Type _resourceType = typeof(TResourceType);

   9:  

  10:     public virtual string ResourcePropertyFormatPolicy

  11:     { get { return "{0}_{1}"; } }

  12:  

  13:     public virtual string UnresolvedValueFormatString

  14:     { get { return "{0}.{1}"; } }

  15:  

  16:     internal string GetResourceValue(string resourcePropertyName)

  17:     {

  18:         // both public and non-public are members are being searched because resource properties

  19:         // will either be generated as internal or public. Optimize this by making it specific to

  20:         // your case.

  21:         var propertyInfo =

  22:             _resourceType.GetProperty(resourcePropertyName,

  23:                                        BindingFlags.Static  BindingFlags.Public  BindingFlags.NonPublic);

  24:  

  25:         if (propertyInfo == null)

  26:             return String.Format(CultureInfo.InvariantCulture, UnresolvedValueFormatString, _resourceType.Name, resourcePropertyName);

  27:  

  28:         return (string)propertyInfo.GetValue(null, null);

  29:     }

  30: }

Next, let’s create a custom rule that outputs a patterned, more identifiable output with a little helper that simplifies the View markup. In this case, we simply override the rules we want to and then create a single live, static instance that is quickly referencable.

   1: public class WebStringResolver : ResourcePropertyResolver<WebStringTable>

   2: {

   3:     public override string UnresolvedValueFormatString

   4:     {

   5:         get

   6:         {

   7:             return "*** {0}.{1} ***";

   8:         }

   9:     }

  10:  

  11:     private static WebStringResolver _instance = new WebStringResolver();

  12:     public static WebStringResolver Instance 

  13:     {

  14:         get

  15:         {

  16:             return _instance;

  17:         }

  18:     }

  19: }

So finally, this leads us to the modified markup that is quite explicit to which resource table it is tied and no magic strings in place.

   1: <div class="editor-label">

   2:     <%=Html.LabelFor(WebStringResolver.Instance, m => m.LastName)%>

   3: </div>

So there you have it- my diversion from reflector-spellunking into the ModelBinder.