Hosting in IIS 8 (on an Azure VM)

[guardrex]

I'm setting up a vNext app server-side (IIS 8 on an Azure VM WS2012):

I have wwwroot folder of files, approot folder of files, test file (related to my dnx command I guess), and a test.cmd file (also related to that dnx command I have setup in project.json). I have these folders and files sitting on a share and setup in IIS just like any garden variety website configuration in IIS. I deleted the default documents.

I setup the path to the site trying both wwwroot and the parent of wwwroot; but when I browse the site, I'm getting 403: Forbidden either way ... what am I missing?

Also, what's the AppPool for these? ... should it be "No Managed Code"

Are there any Advanced Settings for the AppPool that I need to deal with?

[guardrex]

... and I should add that this is a CoreCLR app. I'm interested in setting up IIS 8 without having to use .NET Framework 4.5.1, as the Minimum Requirements call for ... if that's possible.

... and the 403 is not a general folder permissions issue. I have a test.htm file in wwwroot, and that page loads just fine. It's when I browse the MVC portion of the app that the 403 is triggered.

[guardrex]

First issue (probably) solved. Adding Microsoft.AspNet.Server.IIS to project.json took care of the 403: Forbidden per a SO comment to the question by Ricky posted here.

Next issue encountered:

System.InvalidOperationException: Couldn't determine an appropriate version of runtime to run.

I thought with CoreCLR and dnu publish that everything would go with the project? Am I still missing a dependency (or a few)?

"dependencies": {
        "Microsoft.AspNet.Diagnostics": "1.0.0-beta5-*",
        "Microsoft.AspNet.Hosting": "1.0.0-beta5-*",
        "Microsoft.AspNet.Mvc": "6.0.0-beta5-*",
        "Microsoft.AspNet.Server.WebListener": "1.0.0-beta5-*",
        "Microsoft.AspNet.Server.IIS": "1.0.0-beta5-*",
        "Microsoft.AspNet.StaticFiles": "1.0.0-beta5-*",
        "Microsoft.Framework.ConfigurationModel": "1.0.0-beta5-*",
        "Microsoft.Framework.ConfigurationModel.Json": "1.0.0-beta5-*",
        "Microsoft.Framework.ConfigurationModel.Xml": "1.0.0-beta5-*"
    },

[guardrex]

Am I missing values here for the CLR and it's version?

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="bootstrapper-version" value="1.0.0-beta5-11527" />
    <add key="runtime-path" value="..\approot\packages" />
    <add key="dnx-version" value="" />
    <add key="dnx-clr" value="" />
    <add key="dnx-app-base" value="..\approot\src\HelloMVC" />
  </appSettings>
  <system.web>
      <customErrors mode="Off"/>
  </system.web>
</configuration>

... if so, how are these to be populated? manually?

[davidfowl]

I'm interested in setting up IIS 8 without having to use .NET Framework 4.5.1, as the Minimum Requirements call for ... if that's possible.

You need to install ASP.NET on the server. Helios requires ASP.NET >= 4.5.1 even if you wan to run CoreCLR apps on IIS today.

I thought with CoreCLR and dnu publish that everything would go with the project? Am I still missing a dependency (or a few)?

This error:

System.InvalidOperationException: Couldn't determine an appropriate version of runtime to run.

Is talking about the runtime itself (dnx/xre/kre), not the application's packages. Did you include the --runtime switch when packaging? If not, then IIS won't be able to find it an will give the above error.

[guardrex]

I had 4.5.2 on that VM, so I was good there. YES! Thanks @davidfowl ... That got it. It's probably best if I put my steps here for anyone else doing this. There were a few "gotchas" to watch out for:

Note that I'm using nightly builds ... in Adobe Brackets. Therefore, "publishing" was done by manually copying the contents of my output folder to my VM. It should also be possible to use a command like this if you want to try a Web Deploy:

"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -allowUntrusted -source:contentPath="C:\PATH_TO_YOUR_output_FOLDER" -dest:contentPath='SITE_NAME',ComputerName="https://VM_NAME.cloudapp.net:WEB_DEPLOY_PORT/msdeploy.axd?site=SITE_NAME",UserName='YOUR_WEB_DEPLOY_USERNAME',Password='YOUR_WEB_DEPLOY_PASSWORD',AuthType='Basic'

--> Indeed, you do need >= 4.5.1 installed on the server. If it's not installed (and it might not be on a WS2012 (not R2) VM, use the Web Platform Installer to get it.

Note that on WS2012 (not R2) that your sites/app pools will say that they are using .NET Framework v4.0.30319 even when 4.5.x is installed and is the framework in use. Turns out that 4.5.x is an in-place upgrade on WS2012/IIS 8, and 4.5.x will not appear in any dropdown for setting the framework version. Apparently, on WS2012 R2, which came with 4.5.x out-of-the-box, you will see 4.5.x listed and it will show up in dropdowns in IIS 8.5.

If you still have issues, make sure that you go through server Add Roles & Features and check the following are enabled:

Roles: Web Server (IIS) > Web Server > Application Development > .NET 4.5 Extensibility and ASP.NET 4.5
Features: .NET Framework 4.5 Features > .NET Framework 4.5 and ASP.NET 4.5

--> Make sure you have Microsoft.AspNet.Server.IIS in your dependencies in project.json. If you don't have that, you'll get 403: Forbidden when trying to browse the site.

--> Of course, do a dnu restore to make sure everything is up-to-date.

--> Go for a dnu publish --runtime active. This will produce an output directory under bin with your wwwroot and approot folders. If you check the web.config file, it should have populated values for all settings. Without --runtime active, per @davidfowl note above, there will be no runtime and your dnx-clr and dnx-version entries in web.config will not have values. You can add a <customErrors> setting if you run into problems and need to see exceptions in the browser, just be sure to change it for production. Here is what mine looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="bootstrapper-version" value="1.0.0-beta5-11527" />
    <add key="runtime-path" value="..\approot\packages" />
    <add key="dnx-version" value="1.0.0-beta5-11533" />
    <add key="dnx-clr" value="coreclr" />
    <add key="dnx-app-base" value="..\approot\src\HelloMVC" />
  </appSettings>
  <system.web>
      <customErrors mode="Off"/>
  </system.web>
</configuration>

--> Setup your IIS website the way you normally would with a Sites > Add Website and configure normally: the name, set the physical path to the wwwroot folder wherever you placed that on your server/share, and setup the binding information normally.

Note that some SO answers talk about permissions issues and adding IIS_User access to various folders. I did not need to follow those instructions to get the app running. Permissions should be Application user (pass-through authentication) to access the wwwroot folder. That's all you should need, and IIS will default to that setting when you create the site.

--> If you are using a 32-bit CLR, go to the Application Pools area, click on the name of the AppPool for this app, go to Advanced Settings ..., and set Enable 32-Bit Applications to True. If you don't do this, you'll get the exception The specified module could not be found. Of course, if you're going with a 64-bit CLR, then you won't need to do this.

I'm definitely not an IIS expert, so please anyone jump in and correct me or add anything else that I missed.

[guardrex]

CORRECTION: Update to the WebDeploy command that I provided above.

When you run WebDeploy from the command line to publish the app to your VM, you might try providing the IIS website name as I showed above for the -dest:contentPath parameter:

"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -allowUntrusted -source:contentPath="C:\PATH_TO_YOUR_output_FOLDER" -dest:contentPath="SITE_NAME",ComputerName="https://VM_NAME.cloudapp.net:WEB_DEPLOY_PORT/msdeploy.axd?site=SITE_NAME",UserName="YOUR_WEB_DEPLOY_USERNAME",Password="YOUR_WEB_DEPLOY_PASSWORD",AuthType="Basic"

... but that's not going to work. The result of this is that the folders approot and wwwroot don't actually show up where you need them ... inside the F:\mysite folder. WebDeploy/IIS thinks that everything should be in wwwroot (becuase that's the physical path provided for the website in IIS), so what you actually end up with is final paths of F:\mysite\wwwroot\wwwroot and F:\mysite\wwwroot\approot, which is wrong. WebDeploy/IIS will even create a wwwroot folder to hold all of the published folders and files if it doesn't exist.

The way to make it work is to specify the destination explicitly in the WebDeploy command, like this:

"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -allowUntrusted -source:contentPath="C:\PATH_TO_YOUR_output_FOLDER" -dest:contentPath="DRIVE\PUBLISH_FOLDER",ComputerName="https://VM_NAME.cloudapp.net:WEB_DEPLOY_PORT/msdeploy.axd?site=SITE_NAME",UserName="YOUR_WEB_DEPLOY_USERNAME",Password="YOUR_WEB_DEPLOY_PASSWORD",AuthType="Basic"

... note that the destination path for -dest:contentPath is not the IIS website name and it is not the path given to IIS to find the Web.config file (the wwwroot folder) ... it's the drive path to the folder one level above the wwwroot folder ... the folder where you want the published folders/files to land. This was a bit of a rookie mistake on my part, but tricky since we normally WebDeploy directly to the IIS website path.

[flyandi]

THANK YOU! I finally got it working with your instructions.

[guardrex]

@flyandi Sure thing ... glad I could be helpful. The doc team is not going to go this route for publishing to IIS, so I'm going to produce a blog post on it to try and get everything in one spot.