Update publish-iis to set the dll location to home\site\wwwroot\app.dll instead of home\site\app.dll when deploying to App Service

[muratg]

For Antares (App Service) deployments, approot is wwwroot.

cc @BrennanConroy

[moozzyk]

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
  <system.webServer> 
    <handlers> 
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> 
    </handlers> 
    <aspNetCore processPath="%home%\site\wwwroot\HelloMvc.exe" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" startupTimeLimit="3600" /> 
  </system.webServer> 
</configuration>  

[muratg]

Looks good!

[guardrex]

This is confusing given the (philosophical) direction things have gone with wwwroot. It's come to be truly for static file serving. Is this still where Azure Apps will look for web.config? I thought that would be changed (i.e., backed out a level, then searched recursively down folders).

I was looking at what @rmja put up in #105 (comment), and I was sort of expecting that you would go in the ...

processPath="%home%\application\HelloMvc.exe"

... direction with the contents of the publish folder moved into application and the shared framework put into dotnet or something. I'm definitely a little rusty on Azure Apps, but I was basing this on what @rmja posted.

Gut feeling: The closer it is to IIS, the less confusion and the fewer the number of support requests down the road.

I thought you would have something like (standalone) ...

--- application
    --- Logs
        --- dummy `.txt` file (open issue on this bug; folder won't pub without it)
    --- refs
    --- Views
        --- _ViewImports.cshtml, view folders (Shared, Home, etc.), views
        --- DLL's
    --- wwwroot
        --- static files
    --- DLL's, myapp.dll, myapp.exe
    --- web.config

... or shared ...

--- dotnet
    --- shared
        --- assets
    --- dotnet.exe
    --- hostfxr.dll
--- application
    --- Logs
        --- dummy `.txt` file (open issue on this bug; folder won't pub without it)
    --- refs
    --- runtimes
        --- folders for RID's native assets
    --- Views
        --- _ViewImports.cshtml, view folders (Shared, Home, etc.), views
        --- DLL's
    --- wwwroot
        --- static files
    --- DLL's, myapp.dll, myapp.deps.json, myapp.dll, myapp.pdb, myapp.runtimeconfig.json
    --- web.config

[moozzyk]

@rmja - pushed his app with ftp and therefore he controlled where the application went.
Webdeploy apparently deploys to wwwroot and if your app has another wwwroot in your app they will be nested.
Unless it can be changed in webdeploy we don't have much choice and need to set the path so that the app can be found.

[muratg]

@guardrex Perhaps I should have called this out in the issue... Pawel and I talked, so I just filed the bug to track the work. :) The wwwroot in the web.config is not the one that holds your app's static files, but an App Service location.

\home\site\wwwroot is your "application root" in Azure App Service.

So

\home\site\wwwroot
\home\site\wwwroot\app.dll
\home\site\wwwroot\web.config
\home\site\wwwroot\[other root level files and folders like deps file, Views folder etc.)
\home\site\wwwroot\wwwroot
\home\site\wwwroot\wwwroot\(static content, css, html, ...)

Naming is unfortunate. Internally we're talking about changing the default name of the second one.

Hope this makes sense.

[muratg]

@davidfowl FYI. Unfortunately .\app.dll doesn't seem to work (unless something changed in dotnet CLI and make this work)

[guardrex]

Naming is unfortunate. Internally we're talking about changing the default name of the second one.

Exactly. You detected the same thing I did. If it isn't redesigned, it will cost MS some real support money down the road.

However, I don't think the problem is the second one ... the one we're leaning on for static assets in ASP.NET Core projects ... it's the way Azure Apps is setup to host the apps in the first place. If the second (internal) wwwroot name is changed for static assets, it will make things even worse IMO.

Anywho ... I hope for a complete redesign to mirror exactly the way apps will be deployed to folders in IIS (sans the shared framework, which will be a bit different).

Thanks for hearing me out. 😄

[EDIT] The current Azure Apps hosting feels soooo DNX these days! lol

[davidfowl]

@muratg Why can't we just use .\app.dll, why do we need the full path?

[rmja]

I agree with @guardrex, it is the first wwwroot that is causing confusion. That is why I published the app in the example to site\root instead of site\wwwroot being served on mydomain/. This allows for other apps, say an api, to be put in site\api and being served on mydomain/api.

[muratg]

@davidfowl @moozzyk can you elaborate why we can't use .\app.dll?

[mikes-gh]

+1 This is really confusing.
If you change the second wwwroot wont that mean touching all the repos docs etc?