将ASP.NET 5（ASP.NET Core）应用程序部署到Azure的问题

Question

I have an app on ASP.NET 5 (CoreCLR) and I try to publish it to the Microsoft Azure. I using free Web App (not VDS)

I am publishing app using Visual Studio 2015 Publish->Microsoft Azure and following this instructions .

But when I publish it and try to open, I see just non-stop loading of empty page. I enabling logging and view the log (stdout.log) from Azure and there was only:

'"dnx.exe"' is not recognized as an internal or external command,

operable program or batch file.

Also I tried to do Continiusly publishing with git. During push, It started restoring packages and failed with error no disk space available .

Is there any way to publish ASP.NET 5 app to the Azure Web App?

Answer 1

Short Answer

But when I publish it and try to open, I see just non-stop loading of empty page.

This happens when our app fails to publish the runtime ( dnx.exe ) with the application.

Discussion

There are several ways to publish ASP.NET Core rc1 apps to an Azure Web App. These include continuous deployment with Git and publishing with Visual Studio. Post your repository's contents for specific help.

The example is an ASP.NET Core rc1 app, deployed to an Azure Web App, via GitHub continuous deployment. These are the vital files.

app/
    wwwroot/
        web.config
    project.json
    startup.cs
.deployment           <-- optional: if your app is not in the repo root 
global.json           <-- optional: if you need dnxcore50 support

app/wwwroot/web.config

Add the HttpPlatformHandler . Configure it to forward all requests to a DNX process. In other words, tell the Azure Web app to use DNX.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="httpPlatformHandler" 
           path="*" verb="*" 
           modules="httpPlatformHandler" 
           resourceType="Unspecified"/>
    </handlers>
    <httpPlatform 
         processPath="%DNX_PATH%" 
         arguments="%DNX_ARGS%" 
         stdoutLogEnabled="false" 
         startupTimeLimit="3600"/>
  </system.webServer>
</configuration>

app/project.json

Include a dependency on the Kestrel server. Set a web command that will startup Kestrel. Use dnx451 as the target framework. See below for the additional work to target dnxCore50 .

{
  "dependencies": {
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final"
  },

  "commands": {
    "web": "Microsoft.AspNet.Server.Kestrel"
  },

  "frameworks": {
    "dnx451": { }
  }
}

app/Startup.cs

Include the Configure method. This one adds an extremely simple response handler.

using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Http;

namespace WebNotWar
{
    public class Startup
    {
        public void Configure(IApplicationBuilder app)
        {
            app.Run(async (context) =>
            {
                await context.Response.WriteAsync(
                    "Hello from a minimal ASP.NET Core rc1 Web App.");
            });
        }
    }
}

.deployment (optional)

If your app is not in the repositories root directory, tell the Azure Web App which directory contains the app.

[config]
project =  app/

global.json (optional)

If you would like to target .NET Core, tell Azure that we want to target it. After adding this file, we can either replace (or complement) the dnx451 entry in our project.json with dnxCore50 .

{
  "sdk": {
    "version": "1.0.0-rc1-update1",
    "runtime": "coreclr",
    "architecture": "x64"
  }
}

Answer 2

Firstly, yes, you can happily run ASP.Net 5 core apps on Azure, but there are some gotchas.

I don't know why it doesn't work when you publish from Visual Studio itself (so why is he posting an answer I hear you ask...), but here are some things to have a look at;

• Try running in IIS locally (rather than kestrel) - just to see if there is a problem. For example, you need a Web.config with some settings or you need the app.UseIISPlatformHandler in startup.cs.
• Have a look at your global.json file. It shouldn't matter when you publish from Visual Studio but it won't hurt to set this correctly. You can do something like this:

.

{
  "sdk": {
    "version": "1.0.0-rc1-update1",
    "runtime": "coreclr",
    "architecture": "x64"
  }
}

Regarding continous publishing - that is a known problem with free and shared sites and one that cost me a few hours. Basically, when you are deploying by this mechanism and you specify corecelr, the entire runtime is re-installed from Nuget and that takes up nearly 1GB (the allowance for free and shared sites). Add a few NPM packages and you are over the limit and, hey presto, you can't deploy. @shanselman discussed it recently on one of his podcasts. It's not actually the runtime binaries that take up all the space, but because we are in build mode, all the documentation XML files are installed as well, because Nuget doesn't know you are not in a development environment, and they are huge. Right now, the simplest answer if you want to use continuous publishing on a free or shared site is to also include the full runtime in your project.json and set your global.json to use the full CLR instead of the coreclr. Just very frustrating.

Answer 3

I was having the same problem. This answer solved the issue.

When creating a new project with the asp.net core template the global.json file was part of my API project, but it was also referenced in the Solution Items folder. When published to an Azure API app, two global.json files were deployed:

1. In the /approot/global.json
2. In the /approot/src/MyAPI/global.json

I moved the global.json file out of the project folder to the solution root, and re-added a reference back into the Solution Items folder.

When deployed only the /approot/global.json file was then deployed, resolving the issue.