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

[guardrex]

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]

Probably a dup of aspnet/DotNetTools#175

If so, I'll track on the other issue for a fix.

[nil4]

Looking at Microsoft.NET.Sdk.Publish.TransformFiles.targets used by the MSBuild tooling (sorry, I don't know the GitHub URL, but you can find it at %VS2017Root%\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\TransformTargets\Microsoft.NET.Sdk.Publish.TransformFiles.targets) it seems the Web.config "transform" task that adds ANCM bits is conditioned on:
'$(IsWebConfigTransformDisabled)' != 'true'.

I think adding that property to your .csproj might unblock you.

[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]

@guardrex I just updated dotnet-transform-xdt to work with MSBuild/csproj tooling; it's available (but unlisted) on nuget.org. With this update, and dotnet CLI 1.0.0-preview4-004233, I tested your scenario and was able to make it work with the steps below.

Add a Web.RemoveHandlers.config file next to your Web.config with the following content:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <handlers xdt:Transform="Remove" />
  </system.webServer>
</configuration>

Then add the following to your .csproj:

<ItemGroup>
    <DotNetCliToolReference Include="Microsoft.DotNet.Xdt.Tools" Version="1.2.0-msbuild-preview4-004233" />
</ItemGroup>

<Target Name="RemoveHandlersFromWebConfig" AfterTargets="_WebConfigTransform">
  <PropertyGroup>
    <_SourceWebConfig>$(MSBuildThisFileDirectory)Web.config</_SourceWebConfig>
    <_XdtTransform>$(MSBuildThisFileDirectory)Web.RemoveHandlers.config</_XdtTransform>
    <_TargetWebConfig>$(MSBuildThisFileDirectory)$([MSBuild]::MakeRelative($(MSBuildThisFileDirectory), $(PublishIntermediateOutputPath)))Web.config</_TargetWebConfig>
  </PropertyGroup>
  <Exec 
      Command="dotnet transform-xdt --xml &quot;$(_SourceWebConfig)&quot; --transform &quot;$(_XdtTransform)&quot; --output &quot;$(_TargetWebConfig)&quot;" 
      Condition="Exists('$(_XdtTransform)')" />
</Target>

Now dotnet restore and dotnet publish. You'll find the <handlers> section gone from the published Web.config. The key thing is AfterTargets="_WebConfigTransform", which triggers after ANCM handler gets added. Hope it helps.

[guardrex]

@nil4 Yes, except with the starting web.config being the one in the content root, Sdk.Web isn't working to get the processPath, arguments, etc. set in the web.config for deployment.

I tried running it on <_SourceWebConfig>$(PublishDir)web.config</_SourceWebConfig>, but it looks like a file lock prevents it from overwriting the file in published output.

If I change the target to a different filename (web2.config) ...

<PropertyGroup>
  <_SourceWebConfig>$(PublishDir)web.config</_SourceWebConfig>
  <_XdtTransform>$(MSBuildThisFileDirectory)web.RemoveHandlers.config</_XdtTransform>
  <_TargetWebConfig>$(MSBuildThisFileDirectory)$([MSBuild]::MakeRelative($(MSBuildThisFileDirectory), $(PublishIntermediateOutputPath)))web2.config</_TargetWebConfig>
</PropertyGroup>

... starting with a content root web.config (generic, since it doesn't set the processPath and arguments) ...

<?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" />
  </system.webServer>
</configuration>

... output web2.config after the tranform is correct (Sdk.Web ran & transform-xdt ran) ...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    
    <aspNetCore stdoutLogEnabled="true" stdoutLogFile=".\logs\aspnetcore-stdout" processPath="dotnet" arguments=".\testportable.dll" />
  </system.webServer>
</configuration>

[nil4]

I added a repository with a couple of XDT usage samples, including this use case: https://github.com/nil4/xdt-samples

[nil4]

@guardrex Yes, you're right, I see the same issue in the first sample. Let me see if I can find a way around it.

[nil4]

@guardrex Complete silliness on my part; I was trying to write to the output file while the input file was still open, hence the lock error. Thanks for the report, it's fixed in version 1.2.0-msbuild-preview4-004234, published to nuget.org. <_SourceWebConfig>$(PublishDir)web.config</_SourceWebConfig> should work fine now.

[guardrex]

@nil4 Confirmed fixed. Thanks. That's a nice transform system you built. When we get to 1.2 RTM and in the absence of a web.config transform system OOB, I'll see if the docs guys will allow me to link it in the Additional Resources section of the Publish to IIS doc.

[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 aspnet/Tooling#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