Warning: strpos() expects parameter 1 to be string, array given in /home/theserverside/public_html/wp-includes/blocks.php on line 20
{"id":695,"date":"2015-10-18T08:43:30","date_gmt":"2015-10-18T08:43:30","guid":{"rendered":"http:\/\/www.theserverside.technology\/?p=695"},"modified":"2015-10-18T08:51:10","modified_gmt":"2015-10-18T08:51:10","slug":"","status":"publish","type":"post","link":"https:\/\/www.theserverside.technology\/it\/2015\/10\/18\/how-to-run-asp-net-beta8-on-windows-azure-pack-websites-v2\/","title":{"rendered":"","raw":""},"content":{"rendered":"","protected":false,"raw":""},"excerpt":{"rendered":"","protected":false,"raw":""},"author":9,"featured_media":696,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_en_post_content":"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<\/a> (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<\/em> 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.\r\n\r\nYou 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<\/a>\u00a0since we also have free accounts for you to try ASP.NET 5.\u00a0However, 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<\/em>, since this version switches to HTTPPlatformHandler<\/em>. 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.\r\n

[section label=\"Spoiler: scroll down for a quick solution\"] Spoiler: scroll down for a quick solution<\/h3>\r\nThere'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<\/em> 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<\/em> and then provide a quick solution to host it on WAP.\r\n

[section label=\"Publishing your beta8 to your WAP account : Redmond we have a problem...\"] Publishing your beta8 to your WAP account :\u00a0Redmond we have a problem...<\/h3>\r\nSo 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...\r\n\r\n[caption id=\"attachment_707\" align=\"alignleft\" width=\"300\"]\"Publishing<\/a> Publishing your project to file system[\/caption]\r\n\r\n... 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 ?\r\n\r\nIt 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:\r\n\r\n \r\n\r\n \r\n\r\n[caption id=\"attachment_711\" align=\"alignright\" width=\"300\"]\"Windows<\/a> Windows Azure Pack displays an error if you try to run a beta8 project[\/caption]\r\n\r\nNow that's seems odd because up to beta7<\/em>, 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...\r\n

[section label=\"SCM to the rescue: a little diagnostic investigation\"]\u00a0SCM to the rescue: a little diagnostic investigation<\/h3>\r\nMy 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<\/em>, that is to say that it crashed. Remember that Helios has gone and that ASP.NET 5 now is hosted\u00a0through HTTPlatformHandler<\/em> that basically acts like a proxy to dnx.exe, <\/em>like PHP does. So my first thought was to check that this new infrastructure was actually working.\r\n\r\nI logged in to SCM (Service Control Manager<\/em>) 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\r\n\r\n[caption id=\"attachment_717\" align=\"aligncenter\" width=\"300\"]\"WAP<\/a> WAP process explorer - where's Kestrell ?[\/caption]\r\n\r\nAs 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 ?\r\n\r\nIf we look at web.config<\/em> file for our project, that's how HTTPPlatformHandler<\/em> is configured:\r\n\r\n\u00a0\u00a0\u00a0 <httpPlatform processPath=\"..\\approot\\web.cmd\" arguments=\"\" stdoutLogEnabled=\"false\" stdoutLogFile=\"..\\logs\\stdout.log\" startupTimeLimit=\"3600\"><\/httpPlatform><\/em>\r\n\r\nThat basically means that web.cmd<\/em> inside approot<\/em> folder should be spawned when the first request is received. That CMD<\/em> file is a short script that performs some checks then runs appropriate dnx.exe<\/em> and then WAP frontends forward requests to it. My second thought is: does web.cmd<\/em> actually works ?\r\n

[section label=\"Perform checks through Powershell debug console\"] Perform checks through Powershell debug console<\/h3>\r\nSo let's move to Powershell debug console and let's move to \/site\/approot<\/em> folder to check if the whole infrastructure works. Once Powershell console opens, let's run web.cmd<\/em> via console and\u00a0check what happens.\r\n
\r\n
\r\n\r\n[caption id=\"attachment_721\" align=\"alignleft\" width=\"300\"]\"Powershell<\/a> Powershell debug console[\/caption]\r\n\r\n<\/div>\r\n
\r\n\r\n[caption id=\"attachment_722\" align=\"alignright\" width=\"300\"]\"WAP<\/a> Attempting to run web.cmd directly from debug console[\/caption]\r\n\r\n<\/div>\r\n<\/div>\r\nTo my surprise,\u00a0Kestrell runs just\u00a0fine and starts listening\u00a0on port 5000. At least, that's what the console states ! I should switch back to\u00a0Process 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<\/em> actually running inside sandbox, which is encouraging indeed !\r\n\r\n[caption id=\"attachment_726\" align=\"aligncenter\" width=\"300\"]\"dnx.exe<\/a> dnx.exe is now running inside website sandbox[\/caption]\r\n\r\nApart 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.\r\n\r\nSo 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 <\/em>to access that address (http:\/\/localhost:5000) like this:\r\n\r\n(Invoke-WebRequest -URI \"http:\/\/localhost:5000\").content<\/em>\r\n\r\nbecause an error related to Internet Explorer parsing engine occurs. That might be related to sandbox too. Even if I use -UseBasicParsing<\/em> like this:\r\n\r\n(Invoke-WebRequest -UseBasicParsing -URI \"http:\/\/localhost:5000\").content<\/em>\r\n\r\nI 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:\r\n
$url = \"http:\/\/localhost:5000\"<\/div>\r\n
$req = [System.Net.WebRequest]::Create($url)<\/div>\r\n
$req.Method =\"GET\"<\/div>\r\n
$req.ContentLength = 0<\/div>\r\n
$resp = $req.GetResponse()<\/div>\r\n
$reader = new-object System.IO.StreamReader($resp.GetResponseStream())<\/div>\r\n
$reader.ReadToEnd()<\/div>\r\nVery easy and straightforward ! So I ran this script in my PS debug console and\u00a0this one\u00a0was the output I got:\r\n
\r\n
\r\n\r\n[caption id=\"attachment_730\" align=\"alignleft\" width=\"300\"]\"A<\/a> A simple script to send a request to port 5000[\/caption]\r\n\r\n<\/div>\r\n
\r\n\r\n[caption id=\"attachment_731\" align=\"alignright\" width=\"300\"]\"ASP.NET<\/a> ASP.NET response to my request[\/caption]\r\n\r\n<\/div>\r\n<\/div>\r\nAmazing ! 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<\/em> 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 <\/em>running\u00a0when I first looked at Process Explorer. So I can go back to\u00a0Process Explorer and kill dnx.exe<\/em> since now I know it works fine and I need to understand why it doesn't properly start when invoked by HTTPPlaformHandler<\/em>. To do that, I can simply select Properties<\/em> on relevant row and scroll down until I can see the red button. This time pushing the red button is safe...\r\n\r\n[caption id=\"attachment_733\" align=\"aligncenter\" width=\"300\"]\"Killing<\/a> Killing dnx.exe from WAP Process Exporer[\/caption]\r\n

[section label=\"Properly invoking dnx.exe from HTTPPlatformHandler\"]Properly invoking dnx.exe from HTTPPlatformHandler<\/h3>\r\nAt this point we know that beta8<\/em> is working fine on WAP so there must be a problem with HTTPPlatformHandler <\/em>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\u00a0note the red message when trying to manually run web.cmd<\/em> ?) and I thought there must have been a way for Kestrell to communicate with HTTPPlatformHandler to know which port it had to bind to.\r\n\r\nWhile 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<\/a>. 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<\/em> 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.\r\n\r\nJust set DNU_PUBLISH_AZURE<\/em> to true<\/em> 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<\/em> project for Azure. My goal was not to have the project packaged but to check what were the differences between original web.config<\/em> 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:\r\n\r\n <httpPlatform processPath=\"%home%\\site\\approot\\web.cmd\" arguments=\"\" stdoutLogEnabled=\"false\" stdoutLogFile=\"\\\\?\\%home%\\LogFiles\\stdout.log\" startupTimeLimit=\"3600\"><\/httpPlatform><\/em>\r\n\r\nAs you can see, nothing special but a different way to\u00a0tell HTTPPlatformHandler where web.cmd<\/em> and its stdout log (if enabled) were meant to be. No other changes. Could it be so simple ? Gosh!\r\n

[section label=\"How to run ASP.NET beta8 on Windows Azure Pack WebSites v2\"] How to run ASP.NET beta8 on Windows Azure Pack WebSites v2<\/h3>\r\nSo I got back to Powershell debug console, browsed to the wwwroot<\/em> folder and clicked on the pencil icon right beside web.config, <\/em>then replaced HTTPPlatformHandler<\/em> module section with the one DNU prepared for me.\r\n
\r\n
\r\n\r\n[caption id=\"attachment_739\" align=\"alignleft\" width=\"300\"]\"WAP<\/a> WAP debug console allows to browse files[\/caption]\r\n\r\n<\/div>\r\n
\r\n\r\n[caption id=\"attachment_741\" align=\"alignright\" width=\"300\"]\"Using<\/a> Using SCM to edit file web.config directly on target server[\/caption]\r\n\r\n<\/div>\r\n<\/div>\r\nI\u00a0saved the changes\u00a0and restarted my website via tenant portal (don't forget to do this!) and... voil\u00e0 ! My ASP.NET beta8 project was now running fine in Windows Azure Pack !\r\n\r\n \r\n\r\n[caption id=\"attachment_743\" align=\"aligncenter\" width=\"300\"]\"Template<\/a> Template project running on Windows Azure Pack[\/caption]\r\n\r\n \r\n\r\nSo what was the trick ? Apparently, as explained elsewhere on the Internet, HTPPPlatformHandler<\/em> 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.\u00a0The publishing procedure of Visual Studio produced a web.config using relative paths and that was preventing the module to spawn the process.\r\n

[section label=\"Conclusions\"] Conclusions<\/h3>\r\nGoal 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<\/em> 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.\r\n\r\nMeanwhile 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.\r\n\r\nSo if you need to use the newest version, you will need to find a HTTPPlatformModule<\/em>-friendly platform. Want to try ASP.NET 5 beta8 for free ? Head up to VaiSulWeb to activate your free WAP account<\/a> and test your project on a modern platform !","_en_post_name":"how-to-run-asp-net-beta8-on-windows-azure-pack-websites-v2","_en_post_excerpt":"","_en_post_title":"How to run ASP.NET beta8 on Windows Azure Pack WebSites v2","_it_post_content":"","_it_post_name":"","_it_post_excerpt":"","_it_post_title":"","edit_language":"it"},"categories":[8,2],"tags":[164,195,191,121,122,166,171,109,196,194],"_links":{"self":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/695"}],"collection":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/comments?post=695"}],"version-history":[{"count":44,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/695\/revisions"}],"predecessor-version":[{"id":753,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/posts\/695\/revisions\/753"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/media\/696"}],"wp:attachment":[{"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/media?parent=695"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/categories?post=695"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.theserverside.technology\/it\/wp-json\/wp\/v2\/tags?post=695"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}