How to run ASP.NET beta8 on Windows Azure Pack WebSites v2

A few days ago Microsoft released ASP.NET 5 beta8, the first feature-complete version of its flagship Web framework. A lot of expectations come with this new version, both because Microsoft decided to change ASP.NET down to its basis and because this one will be the first multi-platform release for the technology, allowing developers to run their Web or console applications on Windows, Linux and Mac OS X. However, the new version will also be the first one designed from the ground up for the cloud era and thus adopting all methodologies, technologies and conventions that emerged in past few years. As we detailed in a past article (sorry: Italian language only this time!), ASP.NET 5 will also change the way ASP.NET will be hosted on Windows because it will run through the famous HTTPPlatformHandler module that enabled Azure to run basically any runtime, including Java, Python, RoR and more. Later, that module has been channeled down to partners and Windows Azure Pack incorporated it in UR7.

You might be running your website or application on Windows Azure Pack and, if you do, I do really hope that you’re hosting with us at VaiSulWeb since we also have free accounts for you to try ASP.NET 5. However, even if you’re hosting at another service provider, you might be wondering if you will be able to run ASP.NET 5 starting from beta8, since this version switches to HTTPPlatformHandler. Up until beta7, hosting with Azure Pack was very easy: you only needed to publish your project to a folder and then upload that package to your WAP account. Everything was working fine since the very first second.

Spoiler: scroll down for a quick solution

There’s a quick solution waiting for you at the end of this article. If you’re only interested in understanding how you can run ASP.NET 5 from beta8 using WAP, just skip this lengthy explanation and run to the end. This article will be used to as an handy excuse to showcase some nice features that Windows Azure Pack provide its users and that our company provides its customers. We will use such features to understand what’s going on with beta8 and then provide a quick solution to host it on WAP.

Publishing your beta8 to your WAP account : Redmond we have a problem…

So you just started a new project based on ASP.NET 5 beta8 in Visual Studio 2015 or you just created a template project to check how things would shape up. Quick and easy. Now you would like to upload that project to your Web hosting account to check if your provider is compatible with the technology. So you just export your project…

Publishing your project to file system

… publishing to file system, the same way you did up to beta7. Then, after that operation completes, you upload your project on your WAP accounts via FTP or WebDeploy. Compilation time, just a few seconds, and then… uh ?

It seems that something went wrong since no shiny MVC homepage appears in your browser. Rather a very unpleasant message stating that something went wrong with your CGI module and an error occurred. Basically, something like this one:

Windows Azure Pack displays an error if you try to run a beta8 project

Now that’s seems odd because up to beta7, everything seemed to work fine and you might assume that, since WAP is the new kid on the block in hosting technologies for Windows and since it is very close to Azure, ASP.NET beta8 should work on WAP out of the box, like it does on Azure. And you’re right. That’s the same feeling I got but nonetheless, the message Edge displays is quite clear…

 SCM to the rescue: a little diagnostic investigation

My first thought was to check what was going on my server(s) and what was the problem. Usually, when you get such messages your CGI process misbehaved, that is to say that it crashed. Remember that Helios has gone and that ASP.NET 5 now is hosted through HTTPlatformHandler that basically acts like a proxy to dnx.exe, like PHP does. So my first thought was to check that this new infrastructure was actually working.

I logged in to SCM (Service Control Manager) in Windows Azure Pack. By the way, if you never used SCM you’re missing a lot, a magic box to manage and, most important, diagnose your WAP account. My first idea was to check if Kestrell was actually running so I switched to Process Explorer

WAP process explorer – where’s Kestrell ?

As you can see we have two processes (w3wp), one of them is SCM itself while the other one is the website. Kestrell (dnx.exe) is not running so WAP didn’t spawn the process when I tried to access my website. It’s an important information. The problem is: why didn’t WAP spawn the process ?

If we look at web.config file for our project, that’s how HTTPPlatformHandler is configured:

    <httpPlatform processPath=”..\approot\web.cmd” arguments=”” stdoutLogEnabled=”false” stdoutLogFile=”..\logs\stdout.log” startupTimeLimit=”3600″></httpPlatform>

That basically means that web.cmd inside approot folder should be spawned when the first request is received. That CMD file is a short script that performs some checks then runs appropriate dnx.exe and then WAP frontends forward requests to it. My second thought is: does web.cmd actually works ?

Perform checks through Powershell debug console

So let’s move to Powershell debug console and let’s move to /site/approot folder to check if the whole infrastructure works. Once Powershell console opens, let’s run web.cmd via console and check what happens.

Powershell debug console

Attempting to run web.cmd directly from debug console

To my surprise, Kestrell runs just fine and starts listening on port 5000. At least, that’s what the console states ! I should switch back to Process Explorer to check if Kestrell is actually running the way it states so I press CTRL+C and then ENTER to terminate current debug console and then switch to Process Explorer. Now I can see dnx.exe actually running inside sandbox, which is encouraging indeed !

dnx.exe is now running inside website sandbox

Apart from that message about encryption keys, everything seems to be working fine. Kestrell (dnx.exe) is now running inside my SCM sandbox so the last step is checking if it is really able to serve requests because that would mean that ASP.NET 5 beta8 is actually running. As shown in one of the previous images, Kestrell is listening on port 5000 (default one), waiting for connections. However, I just cannot try to connect to port 5000 of the machine on which my application has been published because no connection would be established. Wonders of WAP sandbox, which filters out connections coming from outside current process.

So back to Powershell debug console in order to try to connect to Kestrell and check if it will serve my requests. However, soon I discovered that I cannot use Invoke-WebRequest to access that address (http://localhost:5000) like this:

(Invoke-WebRequest -URI “http://localhost:5000”).content

because an error related to Internet Explorer parsing engine occurs. That might be related to sandbox too. Even if I use -UseBasicParsing like this:

(Invoke-WebRequest -UseBasicParsing -URI “http://localhost:5000”).content

I get an error about a file handle so I tried to find an alternate method, maybe using .NET instead of Powershell cmdlet and I found a smart guy (I lost URL : sorry, mate!) who provided a simple script to solve this problem:

Very easy and straightforward ! So I ran this script in my PS debug console and this one was the output I got:

A simple script to send a request to port 5000

ASP.NET response to my request

Amazing ! ASP.NET 5 beta8 and its Web server Kestrell actually served my request and responded with HTML contents for homepage. That’s very interesting indeed because I can say that beta8 is working fine on WAP when properly invoked. So there must be a problem in invoking Kestrell when first request is received by WAP because I found no dnx.exe running when I first looked at Process Explorer. So I can go back to Process Explorer and kill dnx.exe since now I know it works fine and I need to understand why it doesn’t properly start when invoked by HTTPPlaformHandler. To do that, I can simply select Properties on relevant row and scroll down until I can see the red button. This time pushing the red button is safe…

Killing dnx.exe from WAP Process Exporer

Properly invoking dnx.exe from HTTPPlatformHandler

At this point we know that beta8 is working fine on WAP so there must be a problem with HTTPPlatformHandler since there was no Kestrell running when I tried to invoke beta8 from the outside world. At first I thought it could be something related to port Kestrell was trying to listen on, since I could not see a way for Kestrell to know which port WAP had assigned to it. However, I noticed that Kestrell was actually able to detect it was running on Azure Websites (did you note the red message when trying to manually run web.cmd ?) and I thought there must have been a way for Kestrell to communicate with HTTPPlatformHandler to know which port it had to bind to.

While checking on the Internet, I found out that others were having the same problem I was having and I thought to ask David Fowler for some help. He was kind enough (and quick too!) to provide a hint by stating that I had to use Azure publishing configuration in order to generate the correct web.config to use with WAP. Problem is you cannot publish on your filesystem when you ask Visual Studio to publish for Azure: the tool wants to connect to Azure and directly publish on the cloud. So he revealed that you could use a magical environment variable to ask DNU to package for Azure without actually publishing there.

Just set DNU_PUBLISH_AZURE to true and the trick is served. That was easier said than done, though, since we had to manually invoke DNU. My quest to let DNU run and package the project will probably be a matter of another post however I was able to do that and package my test beta8 project for Azure. My goal was not to have the project packaged but to check what were the differences between original web.config and its Azure counterpart. I was expecting to find a way to pass HTTP_PLATFORM_PORT environment variable from HTTPPlatformHandler to Kestrell as I was pretty sure that was the problem. However, to my surprise, the new section inside web.config was just like this:

<httpPlatform processPath=”%home%\site\approot\web.cmd” arguments=”” stdoutLogEnabled=”false” stdoutLogFile=”\\?\%home%\LogFiles\stdout.log” startupTimeLimit=”3600″></httpPlatform>

As you can see, nothing special but a different way to tell HTTPPlatformHandler where web.cmd and its stdout log (if enabled) were meant to be. No other changes. Could it be so simple ? Gosh!

How to run ASP.NET beta8 on Windows Azure Pack WebSites v2

So I got back to Powershell debug console, browsed to the wwwroot folder and clicked on the pencil icon right beside web.config, then replaced HTTPPlatformHandler module section with the one DNU prepared for me.

WAP debug console allows to browse files

Using SCM to edit file web.config directly on target server

I saved the changes and restarted my website via tenant portal (don’t forget to do this!) and… voilà ! My ASP.NET beta8 project was now running fine in Windows Azure Pack !

Template project running on Windows Azure Pack

So what was the trick ? Apparently, as explained elsewhere on the Internet, HTPPPlatformHandler module doesn’t like relative paths as it needs full path to know what to run and so on. At least, it needs full paths when running in the context of the sandbox that WAP and Azure provide. The publishing procedure of Visual Studio produced a web.config using relative paths and that was preventing the module to spawn the process.

Conclusions

Goal of this post was not only to give you a solution to be able to run ASP.NET beta8 on your Windows Azure Pack account but to show how diagnose a complicated problem using Service Control Manager and powerful tools that WAP provides the developer. Using those tools makes it much easier to understand what’s really going on and usually allows to gather important information to solve most problems.

Meanwhile the trick used to run beta8 is important because the runtime hosting model will not change anymore so this is how you will need to run ASP.NET 5 RTM and most likely any future version of ASP.NET. It is important to notice that, because of runtime hosting model, not all providers will be able to run ASP.NET 5 because they would need to change the way their platforms work.

So if you need to use the newest version, you will need to find a HTTPPlatformModule-friendly platform. Want to try ASP.NET 5 beta8 for free ? Head up to VaiSulWeb to activate your free WAP account and test your project on a modern platform !