Search code examples
c#.net-coreazure-devopsweb-configcsproj

.Net Core 2.2 web.config won't transform LAUNCHER_PATH or LAUNCHER_ARGS on publish in Azure DevOps


I have a simple API project that I can push to Elastic Beanstalk and run on IIS without trouble. The Web.Config (pretty standard), look like this:

<?xml version="1.0" encoding="utf-8"?> 
<configuration>   
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false">
      </aspNetCore>   
    </system.webServer>
</configuration>

When publishing this, the aspNetCore tag gets transformed, with LAUNCHER_PATH & LAUNCHER_ARGS placeholder replaced and hostingModel="InProcess" added (.csproj is set to <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>) to the following:

<aspNetCore processPath="dotnet" arguments=".\xxxxxxxx.Api.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" hostingModel="InProcess">

I have another project that has the exact same web.config file in it, and it transforms when I manually publish (locally), but does not when it is published via Azure DevOps. The YML in both solutions is the same (and both use CreateDefaultBuilder), but in the second project the web.config doesn't get transformed on publish, it stays with LAUNCHER_PATH and LAUNCHER_ARGS and no hostingModel set.

- task: DotNetCoreCLI@2
  displayName: Publish
  inputs:
    command: publish
    publishWebProjects: False
    arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
    zipAfterPublish: True

Note: $(BuildConfiguration) is the same in both projects (Release).

I can hard code the web.config so it doesn't need to transform, but I'd like to know how to solve this properly (especially as we may want to deploy it to linux containers later). I've checked and the .csproj files have the same setup (and package versions), I can't see anything different between the two projects (so I guess I've missed something) besides where web.config lives:

Project that works:

[SolutionDirectory]\[ProjectDirectory]\web.config

Project that does not work:

[SolutionDirectory]\src\[ProjectDirectory]\web.config

The fact that it works locally, but not in DevOps has me stumped. What could cause publish not to transform web.config?

I should note that the project that does work has projects: '**/*.sln' set in the publish task, however setting this on the other project does not resolve the problem (I looked at the artifact produced).


Solution

  • .Net Core 2.2 web.config won't transform LAUNCHER_PATH or LAUNCHER_ARGS on publish in Azure DevOps

    I could not completely reproduce your issue when set **/*.sln in the publish task, I got different result. But if specify the project file instead of solution file in the publish task,like <SolutionName>/**/*.csproj. I could got the same result as I publish on local:

    - task: DotNetCoreCLI@2
      displayName: Publish
      inputs:
        command: publish
        publishWebProjects: false
        projects: '<SolutionName>/**/*.csproj'
        arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
        zipAfterPublish: True
    

    Then I could got two .zip file, and unzip them, I could found web.config transform as expect:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
        </handlers>
        <aspNetCore processPath="dotnet" arguments=".\WebAppTransform.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" hostingModel="InProcess"></aspNetCore>
      </system.webServer>
    
    </configuration>
    

    Hope this helps.