Tuesday, 14 February 2012

DotNetOpenAuth 4 beta with Windows Azure

Recently I blogged about using DotNetOpenAuth, I got it working within my local MVC3 Web Application after fixing the dependency issue however when I came to put it into Windows Azure I was getting a random error when the compute emulator started up.

Microsoft Visual Studio
Windows Azure Tools for Microsoft Visual Studio

There was an error attaching the debugger to the IIS worker process for URL '' for role instance 'deployment16(174).xxxxxxxxxxx_IN_0'. Unable to start debugging on the web server. See help for common configuration errors. Running the web page outside of the debugger may provide further information.

Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start Without Debugging. You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation.

Nice! How confusing, the compute process didn't even startup but yet if I run it using the built in webserver all is fine. I knew it had to be related to DotNetOpenAuth as this was the only thing I had changed in my project since the last successful run.

So I started looking into the issue, now I knew it worked on the local dev server however I realised that it wasn't using IIS7 or IIS7.5 but the built in VS. This doesn't run anywhere near the same as IIS7.x which is what Azure is built upon. So I switched my MVC3 Web Application to use IISExpress, which is a lightweight version of IIS, and fired up the app.

I instantly got where the error message was:

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Config Source:

    7:   <configSections>
    8:     <section name="uri" type="System.Configuration.UriSection, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> 
    9: <sectionGroup name="dotNetOpenAuth" type="DotNetOpenAuth.Configuration.DotNetOpenAuthSection, DotNetOpenAuth">

This section element wasn't needed, .Net 4 already includes System.Configuration.UriSection within the machine.config This is trying to load the v2 component, which is required for .Net 2 - .Net 3.5.

So where did it come from? Well the answer lies with NuGet, I had installed DotNetOpenAuth using Nuget
Install-Package DotNetOpenAuth -Pre
Which along with the library references updated the web.config. The error here is not checking what .Net version the project is before it updates the web.config with the required sections.

As this is a prerelease version of DotNetOpenAuth my guess is it will be fixed before release, I'll be raising it as an issue any how.

Hope this helps.

Monday, 13 February 2012

Using DotNetOpenAuth and getting "DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult"

Today I started integrating OpenID into my latest web application. I chose to use the DotNetOpenAuth library as a helper, it's top and makes Open ID really easy, supports Web Forms, MVC and even classic ASP. Anyhow there are many how too guides, including one from my good friend Danny Tuppeny, so when it comes to setting it up I refer you to those.

However today I found when I was using the AsActionResult extension method my web page would come back blank with just  DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult written on screen. For some reason the ToString was being called and returned.

Commonly it seems that the issue is caused by not having a binding redirect for older versions of the MVC assembly however my one was set, but what I did notice was the following:

        <assemblyIdentity name="DataAnnotationsExtensions" publicKeyToken="358a5681c50fd84c" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="" />
The  DataAnnotationsExtensions also had an assemblyIdentity reference to MVC and this was set to version 2. But I was using MVC 3, so I believe what is happening is that the assembly redirect is looking at the first option and then using the wrong version.
I simply removed this redirect and let the main one be used and everything kicked back in.
A lesson learned :)