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 'http://127.255.0.0:82/' 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=2.0.0.0, 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.

Comments

Post a Comment

Popular posts from this blog

WebUSB - An unexpected update...

Image
In January at my new(ish) user group Momentum Meetups , I presented on "Reaching out beyond the Chrome" (although suffering from food poisoning so I was definitely going green at points!). It included  WebUSB and WebBluetooth . I was excited by how powerful it was and even had a colleague present something we had been prototyping in out work place. During the talk I mentioned security and how it had been designed so it only works on https and there's a permission model where you have to approve the device before it can be used. Unfortunately this week it came to light that Authentication devices could be bypassed via USB. These devices are a great way of proving you are who you say you are on the web beyond basic 2FA text's or applications. So being able to be able to bypass them via WebUSB is a big deal :( My Original Security Slide A few days later Google then disabled WebUSB by default effectively killing it off until such a time where its made secure...
Read more

Can you use BuildRoot with Windows Subsystem for Linux......

Image
A quick note I started this blog post back in August of 2018 and never completed it. Essentially I wrote most of it and then found I just couldn't run BuildRoot properly, I came back to it every Windows 10 release due to performance improvements etc however its only now with WSL2 that this is possible. Read on to find out the full story :) Original Post I love Windows Subsystem for Linux , I mention it all the time in work, done "brown bag" sessions on it, even did a lightning talk on it at DDDSW 18 . This week I've been working with a contractor to produce essentially an Embedded OS for a project. Previously I've always used existing distributions and made them "lite" or used preconfigured ones, Raspbian Lite for example however he promptly told me I'm doing it wrong and that I shoudl be using BuildRoot. Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. Sound's interest...
Read more

DotNet CLI , private NuGet feeds and Linux...

Today I hit an issue whilst trying to run dotnet run for some of our benchmarkdotnet tests which I like to run all new hardware I try out. My pair of Raspberry PI 4's arrived and I wanted to compare the performance of our Fingerprint capture code. I've hit the issue before and last time I figured it out I swore I'd blog and write it up as I knew I would forget! My benchmark project is a straight forward BenchmarkDotNet project however it consumers NuGet packages from both nuget.org as well as our private NuGet repository which requires authentication. For all of our windows machines this works without an issue for machines on the domain they authenticate seemlessly however when using Linux devices this is a different issue :( Instead on Linux devices we always get: /home/pi/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :   GSSAPI operation failed with error - An invalid status code was supplied (SPNEGO cannot find mechanisms to negotiate). This essentially means it ...
Read more