At the beginning of October Microsoft Finland held the yearly developer conference, this time with name Devdays. This year’s conference felt slightly smaller than previously.

As there is is lots of churn around the ASP.NET right now and I have a history with that framework, I proposed a presentation about ASP.NET vNext. Gladly it got accepted, and I had to dig deeper into what’s coming from the ASP.NET team. I played with the framework, watched every video and and read every blogpost about it from Scott Hanselman, David Fowler and others. I also prepared some demos, even a Linux demo which I had to scrap on last minute because I had only 45 minutes time to present. I tried to give the audience some guidelines how they can prepare to what’s coming, in order for the upgrade from current ASP.NET to be as easy as possible. It was nice to prepare and present, I hope it helped someone.

P.s. I waited for Microsoft to release the video recordings before posting this, but still after two months there is only a couple of videos available, and they are on strangely named Youtube channel, different from previous years. I do not know what happened as I have not seen any communication from MS about the recordings, and I have yet received no answer to my question. So I have to say this aspect of the conference was poorly executed this year. Also, there was no common feedback collection, which means that presenters did not get any proper feedback. For me it is important to see the video and get some feedback to be able to do better next year.

I changed some of my websites deployment to use different deployment slots on a single Azure web site instead of having different web sites for different staging areas. I deploy all my staging areas automatically from TFS (using the GitContinuousDeploymentTemplate.12.xaml process), each area from different Git branch. Works for my setup.

What did not work was deploying to other slots than the main slot. On Azure portal different slots have name and address scheme like mywebsite-slotname. I tried to use this name as deployment target:

Failing configuration.
Failing configuration.

…and got failed build with error like:

An attempted http request against URI https://management.core.windows.net/long-guid-string-here-53e1f2/services/webspaces/WestEuropewebspace/sites/mywebsite-slotname/publishxml returned an error: (404) Not Found.

So clearly mywebsite-slotname is not the correct scheme. And there is no documentation available, thus this blog post.

I went on and downloaded publishing profile for the site slot. It had double underscore naming mywebsite__slotname, but that did not work either. Nor did single underscore. What finally worked, was the name the old Azure portal used: mywebsite(slotname). This is how my build process deployment target looks now, and deployment to the slot works.

Working configuration.
Working configuration.

I hope this gets better documented. Luckily one can create pull request for Azure documentation nowadays; I might document this myself.

Since Office 2013 was launched, I’ve had some problems with Outlook and account settings: I can set up all the accounts, but Outlook refuses to display my default Exchange calendar on the todo-pane, and instead shows an empty calendar from one of the other accounts that I use for email only. I like the todo-pane as its easy to glance whats coming with it. I’ve searched for resolution a couple of times, and most Microsoft community answers suggest to change the default data file on via Outlook > Account Settings:

Outlook default data file settings

Unfortunately changing that setting back and forth does not affect what’s shown on the todo-pane; I already had my Exchange account as default. Next suggestion I found was to change the same setting via Windows Control Panel’s mail section:

Control panel mail settings

…but that was exactly the same setup than the previous one done via Outlook, nothing changed. Out of curiosity I decided to check what’s under the mail profiles section.

Control panel mail profiles

And from there I hit properties, and under properties you can find yet another data file selection dialog. Changing this data file under the profile finally changed my Outlook’s default calendar. Shouldn’t be this hard.

Control panel mail setup for a profile Default data file for a profile
Yet another place to set the default Outlook data file.

I visited my local pharmacy last Friday to get some prescription drug. I sat in front of the pharmacist, who gave me very thorough guidance about the usage. At the time of payment - before she handed me the boxes - she suddenly said:

Excuse me, but I need to get a signature from someone else, as I am a trainee.

Immediately another pharmacist came by, put her smart card into the computer, checked the boxes against the electronic prescription, and then signed the delivery. The whole process took maybe 20 seconds, and I’m certain trainee felt safer as her work is checked against mistakes. And myself - as a client - I felt like they care.

With the risk of sounding like Uncle Bob: this episode reminded me about how one should act if you really care about quality. This model of signing other people’s work is built into some software development processes, like the Github flow. If you are not using pull requests, you can still simulate this kind of apprenticeship model with strict use of code reviews before merging into your trunk. Remember, that this must not be for all your codebase; you can be very strict on important, core modules, and let others evolve freely.

OWIN stands for the “Open web interface for .NET”. Basically it is a reasonably simple specification that defines how data goes through the request pipeline, and how to attach to that pipeline. It is a specification for both the server and the application (middleware on OWIN’s terms) part.

When I first saw the project I was not that convinced, but since then lots of applications that rely on OWIN and not the old System.Web stack has emerged, and also there are some hosting components that implement the spec. SignalR is a good example of middleware, and Katana a host. For me the new project Helios is also very interesting and I hope the project succeeds, as that would make hosting ASP.NET WebApi very lightweight. And light is never bad.

So the ecosystem has matured, then what? What really made me to support OWIN is what it did to my codebase. In one of my pet projects I use claims based authentication and authorization with Windows Azure Access Control Services; That is a great project (although being replaced with Azure AD), but on the .NET MVC application side it has been a pain to integrate. The amount of web.config carbage it needs is huge, and I have broken it multiple times. Luckily Microsoft released some OWIN-based implementation of the server side components, and promised drastically simplified configuration model. You just register th middleware to OWIN, specify where to find the metadata, and give the application identifier:

public void ConfigureAuth(IAppBuilder app)
{
    app.UseCookieAuthentication(
        new CookieAuthenticationOptions
        {
            AuthenticationType = 
               WsFederationAuthenticationDefaults.AuthenticationType
        });

    app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
        {
            MetadataAddress = "https://login.windows.net/some-azure-ad.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml",
            Wtrealm = "http://myapps/somerealm",
        });
}

For me simplified configuration was not the only benefit: OWIN registration also gave me an option to register everything authentication related at the same place, which makes the code very readable. Before OWIN I had :

  • Various XML configurations for WS Federation registration
  • Custom ClaimsAuthenticationManager to do in-the-app claims transformation (look for database for some extra information and include that in claims)
  • Account controller to handle sign in and sign out actions
  • Handler to add user’s roles to all outgoing request for better usability (hide client side elements on single page application based on user’s role)

Now I have instead something along these lines:

public void ConfigureAuth(IAppBuilder app)
{
	app.SetDefaultSignInAsAuthenticationType(WsFederationAuthenticationDefaults.AuthenticationType);
	app.UseCookieAuthentication(
		 new CookieAuthenticationOptions
		 {
			 AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType,

			 // Make claims transformation to avoid using an external 
			 // STS to map certain users to certain role claims
			 Provider = new CookieAuthenticationProvider
			 {
				 OnResponseSignIn = ctx =>
				 {
					 ctx.Identity = TransformClaims(ctx.Identity);
				 }
			 }
		 });

	app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
	{
		MetadataAddress = ConfigurationManager.AppSettings["medatata"];,
		Wtrealm = ConfigurationManager.AppSettings["realm"];
	});

	// Map sign in action
	app.Map("/signin", map =>
	{
		map.Run(async ctx =>
		{
			if (ctx.Authentication.User == null ||
				!ctx.Authentication.User.Identity.IsAuthenticated)
			{
				ctx.Response.StatusCode = 401;
			}
			else
			{
				ctx.Response.Redirect("/");
			}
		});
	});

	// Map signout action
	app.Map("/signout", map =>
	{
		map.Run(async ctx =>
		{
			ctx.Authentication.SignOut();
			ctx.Response.Redirect("/");
		});
	});
}

private static ClaimsIdentity TransformClaims(ClaimsIdentity identity)
{
	// ... add what ever claims needed based on your own data source
	return identity;
}

Kudos for Dominick Baier for his clear post on this subject that helped me forward with sign in and out actions.

WebApi + OWIN

At the same time I also moved Web API to OWIN based hosting, even though I actually run on IIS. Reasoning was the same than with claims auth: I find the configuration model better.

If you’re an ASP.NET developer, I suggest you start experimenting with the OWIN pipeline. It will pay out.