Publishing default ASP.Net Core Web app template to azure doesn't modify the log location in web.config, resulting in no logs being produced #540

[moozzyk]

With the project created from templates the log path is set to be .\logs\stdout. If the user turns on logging but does not modify the path or delete the attribute the path will be used as is (publish-iis does not change path as it might have been set by the user). When publishing this project for Azure the path won't be correct and no logs are written.

More details:
See: https://github.com/aspnet/Tooling-Internal/issues/540

Need to decide what we want to do.

[muratg]

@moozzyk is the change in publish-iis command or the templates?

@Eilon @DamianEdwards do we want to fix this for RC2?

cc @danroth27 @glennc

[moozzyk]

I don't think it can be done in templates (or only in templates). When the application is being created you don't know whether it's going to be published for Azure or IIS. When publish-iis is invoked we know if we are publishing for Azure or not. This is when we have a chance to react. The question is how we should know whether to react. One option is to not put stdoutPath to the web.config by default (this would requires changes in templates) at all. In this case publish-iis will set the path accordingly. Another way is just to leave the templates alone as today and have publish-iis check the value - if the stdoutPath has the default value it would be overwritten otherwise it would be not touched to not overwrite something the user set. In this case the changes are needed only in publish-iis tool.

[Tratcher]

The other alternative is to have the templates set the log path to %LOG_PATH% like we do for the app and args. Then it publish-iis could check for this default and replace it for normal or azure publish.

[DamianEdwards]

If we can make a very simple fix (aka extremely-low-risk) to the templates ASAP then I'm OK with this for RC2. Otherwise, we should revisit this in RTM.

[davidebbo]

Today, when git deploying an app to Azure, you end up with this in web.config:

<aspNetCore processPath="dotnet" arguments=".\AspNetCoreRC2.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />

To enable logging (including streaming), you need to change it to:

<aspNetCore processPath="dotnet" arguments=".\AspNetCoreRC2.dll" stdoutLogEnabled="true" stdoutLogFile="%home%\LogFiles\dotnetcore" forwardWindowsAuthToken="false" />

But Azure Web App already has an existing mechanism to enable logging, and it would be good to just honor it. It works as follows:

• there is a file called settings.json in %home%\site\diagnostics
• it contains something like this: {"AzureDriveEnabled":true,"AzureDriveTraceLevel":"Error"}
• if AzureDriveEnabled is true, it logs to files in %home%\LogFiles\Application

[moozzyk]

The setting.json based logging mechanism uses .NET tracing - so it's tracing from the application. Here we are talking about IIS capturing whatever was written to standard output and dumping it to a file. Very useful for troubleshooting issues (e.g. startup) but probably not as much for application logging. Application can configure logging and decide to log elsewhere in which case these entries won't show up in stdOutLog. We will hover need to verify if the setting.json based Azure logging mechanism can be used to write application logs.

[moozzyk]

We decided to overwrite the outpath always to "?%home%\LogFiles" when publishing for Antares since the stdoutLog should be used for diagnostic purposes and the folder always exists.