@robdmoore

I’m happy to announce that I’ve just released AzureWebFarm 0.9.2 to Nuget.

This release involves months of work by myself and Matt Davies to really tighten up the farm, perform a lot of stress testing on it (including some reasonably heavy production loads) and take the (larger than we expected - I’ll do a separate blog post on this in the next few days) step to upgrade to Windows Server 2012 / .NET 4.5 support. We will be deploying this version to production farms over the next few weeks and if there are no issues then we will be releasing v1.0 in the near future.

I’m pleased to announce that with Windows Server 2012 and the Azure SDK 1.8 (which we’ve discovered comes with some quite massive and seemingly undocumented deployment speed improvements that we are reliably getting deployment times (including package upload) of around 9 minutes for a new web farm!We think this is incredible that you can get anenterprise-grade, clustered, load-balanced, IIS8 / Windows Server 2012 powered web farm with background execution capabilities that you can scale up and down in less than 10 minutes!!!

What’s new?

The changes we’ve introduced in this version are (in no particular order):

• If a web.config file is included with a background worker application then it will no longer cause an exception in the web farm and in fact will not be overwritten
• Upgraded to Azure SDK 1.8 along with the deployment speed improvements this entails
• Decreased the number of files that are needed in the web farm web project significantly (now it’s just web.config, app.config, Probe.aspx, Probe.aspx.cs and WebRole.cs)
• Added missing HTTP certificate config in the example cloud project config files
• Set a bunch of internally used classes to internal from public to reduce the possibility of any confusion
• Refactored core code to make it easier to unit test and maintain
• Improved the test coverage of the codebase
• Changes to config settings while the farm is deployed will now update the farm without requiring the roles to be manually restarted (the roles won’t automatically restart either - they will always use the latest version of the config settings)
• Added handling to OnStop to ensure all ASP.NET requests are served before a role is restarted as per http://blogs.msdn.com/b/windowsazure/archive/2013/01/14/the-right-way-to-handle-azure-onstop-events.aspx
• Added configurable logging via Castle.Core so you can adjust the verbosity of the trace logs and intercept the logs if you would like to redirect it to different instrumentation
• Removed dependencies on Azure Storage within uncaught code called from OnRun() - this means that the web farm should not go down if there is an Azure Storage outage
• Added configuration setting to allow for syncing to be disabled without needing to redeploy the farm
• Added functionality to ensure all web deploy connections get funnelled to a single role instance at a time (with robust failover if that role instance fails). This resolves an issue when using MsDeploy v3+ on the server that we discovered and will be documented in a later blog post.
• Changed the example config files to use Windows Server 2012
• Opened up a readme.txt file when you install the NuGet package to outline any breaking changes
• Improved documentation on github

Breaking Changes

If you are upgrading from a previous version of Azure Web Farm then make sure you look at the breaking changes file to see upgrade instructions as there are a number of breaking changes in this release.

Future Direction

What’s in store for Azure Web Farm in the future? This is a rough idea of the sorts of things we are looking into (we don’t have a timeline on this - if you want to help out to make it happen faster though please contact us):

• Out of the box auto-scaling support using Wasabi
• Better installation experience - using nuget install scripts to take away some of the tedious manual configuration when creating a new farm
• Improving the syncing speed - it currently takes 30-90s to sync a new deployment across the farm and we are confident we can get that down significantly

Read More

Lately I’ve been spending a fair bit of spare time working hard on getting the TestStack.Seleno project ready for a (rather massive!) 0.4 release. It’s been a lot of fun and I’m quite proud of the impact the core TestStack team and other contributors have made on the library. We feel that it is “production ready” now and will be moving towards a 1.0 release in the somewhat near future.

I won’t bother going into a huge amount of detail on the release because Michael Whelan has done that already, but I’ll list down the major changes here as a tl;dr:

• Added a bunch of global configuration options:
  • Ability to specify a Castle.Core logger factory to intercept our internal logging
  • Ability to more easily specify a non-Firefox web browser
  • Ability to specify a deployed web application out-of-the-box
  • Ability to more explicitly specify your MVC routes
  • Ability to override the minimum (implicit) wait timeout inside of Selenium
• Ability to explicitly specify the initial page for a test and initialise the first page object in one line of code
• Continuous Integration support (now runs in TeamCity)
• A new HTML Control model that provides a nice API on top of Selenium Web Driver to interact with HTML controls (including easy extensibility for your own controls)
• A clearer public API
• Improved test coverage and extensive refactoring of the core library code

You can get the latest version of Seleno on NuGet, or check out our GitHub repository for the latest source code and the getting started documentation. Let us know what you think, or if there are any features that you would like to see. Feel free to add an issue or pull request - the more community interaction we get the better we can make Seleno!

Read More

This week I had an issue raised on my Github site for examples of unobtrusive validation with ASP.NET MVC. The person that raised the issue was having a problem where they wanted their fluent validation modules to be singleton, but they wanted to inject a factory that can be invoked to return a request-scoped object (in this case some sort of database store). Inevitably they came across the “No scope with a Tag matching ‘AutofacWebRequest’ is visible from the scope in which the instance was requested” error.

I’ve blogged previously about a technique for using DependencyResolver.Current and being able to unit test it for similar situations. It’s not a great solution, but it does work and at least it can be unit tested.

Low and behold though, thanks to the power of the Internet, the person that raised the issue asked a question on StackOverflow and got a really elegant solution for how to inject factories in a singleton that will correctly resolve request-scoped objects. I’m pretty excited about it so I thought I’d give it more exposure by doing this blog post.

This is the technique in all it’s glory (I’ve renamed the method name slightly to make it more readable):

public Func<T> HttpRequestScopedFactoryFor<T>()
{
    return () => DependencyResolver.Current.GetService<T>();
}
...
builder.RegisterType<SomeRequestScopedComponent>().As<ISomeRequestScopedComponent>().InstancePerHttpRequest();
builder.RegisterInstance(HttpRequestScopedFactoryFor<ISomeRequestScopedComponent>()); // this is the magic bit

This will then allow you to do something like this:

builder.RegisterType<SomeSingletonType>().As<ISomeSingletonType>().SingleInstance();
...
public class SomeSingletonType
{
    private readonly Func<ISomeRequestScopedComponent> _someRequestScopedComponentFactory;
    public SomeSingletonType(Func<ISomeRequestScopedComponent> someRequestScopedComponentFactory())
    {
        _someRequestScopedComponentFactory = someRequestScopedComponentFactory;
    }
    public void SomeMethod() {
        var requestScopedComponent = _requestScopedComponentFactory();
        ...
    }
}

Nice and even easier to unit test than using DependencyResolver.Current directly!

Big thanks to @thardy and @felix.

Read More

I’m proud to be able to announce the release of version 1.0 of NHibernate.SqlAzure!

This library takes care of retrying when the transient errors that SQL Azure throws at you occur while using the NHibernate ORM. It’s been in Beta for the last few months and has been successfully used on a number of production websites.

Changes from 0.9 to 1.0

• Bug fix when using Schema validation (thanks to @hmvs)
• There is now a transient error detection strategy and associated NHibernate driver (SqlAzureClientDriverWithTimeoutRetries; say that 10 times fast!!) that retries for timeout exceptions (see the Github page for details and also thanks to @hmvs for a contribution towards this)
• Some instances where exceptions were wrapped in NHibernate exceptions (batching, transactions) are now picked up as transient exceptions when before they were ignored
• You can now easily log connection and command exceptions separately (see the CommandRetry and ConnectionRetry virtual methods on the driver class you use)
• The documentation is a bit more comprehensive now
• I finished writing all the automated tests I wanted to
• Been road-tested on a number of sites over the last few months in production

This project is a collaborative effort along with my partner in code crime - Matt Davies - all code was either pair programmed together or reviewed by the other party.

Go and grab it from NuGet today and let me know how you go! Installation / usage instructions are on the Github page.

Read More

I’ve previously blogged (as a side-note of an unrelated problem I was having) the approach that I use to overcome the problem that the AspNetCompiler has when you have the extraneous web.config files in the obj folder after creating a web deploy package.

The usual way you will come across this problem is running MvcBuildViews in a subsequent build after creating the package. The solution that I previously posted included a few MSBuild targets that can be called prior to running MvcBuildViews to clean up the web deploy files.

If you have tried using these targets after upgrading your project to Visual Studio 2012 then you will have noticed that some of the targets no longer work because they have been renamed. The following code is what I now use and it is compatible with the Visual Studio 2010 round-tripping support.

  <Target Name="CleanWebDeploy" BeforeTargets="MvcBuildViews" Condition="'$(MvcBuildViews)'=='true'">
    <Message Text="Running Clean Web Deploy Target" />
    <CallTarget Targets="CleanWebsitesPackage" />
    <CallTarget Targets="CleanWebsitesPackageTempDir" Condition="'$(VisualStudioVersion)'=='10.0'" />
    <CallTarget Targets="CleanWebsitesTransformParametersFiles" Condition="'$(VisualStudioVersion)'=='10.0'" />
    <CallTarget Targets="CleanWebsitesWPPAllFilesInSingleFolder" Condition="'$(VisualStudioVersion)'!='10.0'" />
    <CallTarget Targets="CleanWebPublishPipelineIntermediateOutput" Condition="'$(VisualStudioVersion)'!='10.0'" />
  </Target>

Read More