<handlers> section is added to web.config when explicitly removed from source file

The Sdk (or perhaps to me more precise Sdk.Web) is explicitly adding the <handlers> section to web.config even when I have explicitly removed it.

If the project includes a source web.config such as this …

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore stdoutLogEnabled="false" stdoutLogFile=".\logs\aspnetcore-stdout">
    </aspNetCore>
  </system.webServer>
</configuration>

on dotnet publish, the web.config file that appears in published output is …

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule"
          resourceType="Unspecified" />
    </handlers>
    <aspNetCore stdoutLogEnabled="true" stdoutLogFile=".\logs\aspnetcore-stdout" 
          processPath="dotnet" arguments=".\testportable.dll">
    </aspNetCore>
  </system.webServer>
</configuration>

The reason this is a problem is that my app in this case is a subapp, which cannot have a <handlers> section. Every publish, I must manually delete the <handlers> section in the published output web.config.

[guardrex]

Thanks @nil4 👍

Adding …

<IsWebConfigTransformDisabled>True</IsWebConfigTransformDisabled>

… to the <PropertyGroup> stopped the transform, thus it prevented my web.config from being modified and having the <handlers> section added to it.

The only thing devs need to keep in mind is that their web.config will only be moved. Devs will need to set the processPath and arguments manually in their source file prior to publishing/deploying an app.

Use of this property is probably “the answer” to this issue, so I’ll close.

[nil4]

It’s just a quick-and-dirty port of the CodePlex XDT code to .NET core, with known weaknesses around whitespace preservation and missing unit tests (as you can probably tell from the bug you just found 😀). It works well enough for my own needs, and apparently it’s useful for other people too. If there’s a chance to link it from the docs, that would be great. 👍

If (or rather when) you guys get to https://github.com/aspnet/Tooling/issues/780, I would be happy to hand over the ownership of the NuGet package if that’s something you are interested in. I published the first version under a Microsoft.* name without thinking. /cc @sayedihashimi