Typically with ASP.NET Core 3.1 when no specific authorization requirements are set all endpoints are publicly accessible. When you’re wo...asp.net core
Thanks for the post!— Mickaël Derriey (@mderriey) January 21, 2019
If you don't want to create a web.config, you can also drive this through the <AspNetCoreHostingModel> MSBuild property by setting it to InProcess in the .csproj.
Using the SDK v2.2.102, <AspNetCoreModuleName> default value is already AspNetCoreModuleV2.
So after publishing this post, a nice individual by the name of Mickaël suggested that the
dotnet-cli automatically creates this web.config based on the the
csproj settings. It does indeed work! I do suggest you make sure you are on the latest
2.2.100 or else you won’t see the results you are looking for.
Note: The build process may suggest that you do not include the version number in your PackageReference. I was not able to get Azure to successfully load the ASP.NET Core application without specifiying the package version of
2.2.1. Try it both ways and see what happens.
Thanks again to the folks who read and suggest better solutions.
The year is 2019, and you’ve decided to live on the bleeding edge at the intersection of ASP.NET Core and Windows Azure. ASP.NET Core delivered
InProcess hosting With the release of ASP.NET Core 2.2, which means our applications can take full advantage of IIS resources and be hosted in the IIS Process itself. This post will show you the steps you need to take to make your ASP.NET Core Application work in Azure.
You will need the latest version of
Microsoft.AspNetCore.App which is 2.2.1 as of this post. Once installed via NuGet, you should have a package reference like so:
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.1" />
This is where you may be scratching your head. Why do I need a
web.config. While the application may be ASP.NET Core, it is hosted in IIS which still uses configuration files.
This configuration file test IIS to use the correct module when running the ASP.NET Core application. The web.config is critical.
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" <!-- Your Application Dll Goes Here --> arguments=".\MyApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" /> </system.webServer> </location> </configuration>
The reason we need a
web.config is due to the handler element, which is set to
If you’re hosting in App Services, be sure to install the ASP.NET Core Logging Extensions. It will help you debug issues more easily by enabling the
Diagnostic logs feature in your App Service instance.
There you have it. Your ASP.NET Core application is ready to be hosted
InProcess and utilize IIS. You should see a nice performance boost and faster startup times as well.