Closed phatcher closed 6 years ago
@phatcher , Can you try XML transformation
in App Service Deploy task to transform your web.config as required?
More info here.
@vincentdass I tried a web.Release.config like this...
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="" xdt:Transform="Remove" xdt:Locator="XPath(system.webServer/handlers[@name='aspNetCore'])" />
</handlers>
</system.webServer>
</configuration>
but it didn't work
@phatcher , Can you try the following Transform file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="aspNetCore" />
</handlers>
</system.webServer>
</configuration>
@phatcher , closing the thread, as the above transform file should have resolved the issue.
@vincentdass Sorry, was on holiday last week - I've tried the config transform and it's not working; the deployment log says that it has applied the transform and web.config/web.Release.config are present in the deployment directory.
It also doesn't work if I try this in Visual Studio (15.7.4) using the Preview Transform which I presume is using the same ctt.exe under the hood?
For reference I have a web.config with
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
and a web.Release.config with
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="aspNetCore" />
</handlers>
</system.webServer>
</configuration>
The config files are set to Content and Do Not Copy but they are present in the published artifact
@phatcher , transform files are not removed after transformation, so they are deployed along with config file.
Can you try the following transform file instead:
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<handlers>
<add name="aspNetCore" xdt:Transform="Remove" />
</handlers>
</system.webServer>
</configuration>
verified with config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
You can verify it online here.
The above transformation should result in
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
@vincentdass Thanks that one worked!
So it's basically using the standard web.config transform syntax?
And just to confirm, for a specified environment transform to work a web.XXX.config file must exist matching the VSTS environment e.g. if you have an Staging environment you must have a web.Staging.config if you want to have specific work to happen?
@phatcher , yes, you are correct, additionally, Web.Release.config
is applied prior toWeb.< Env Name >.config
Environment
Issue Description
Build a solution containing multiple webs which I need to deploy into Azure as a main web and virtual applications.
Problem I am hitting is invalid web.config in the virtual applications as they contain the asp.net core handler (see IIS Configuration of sub-applications
Looking for advice as to the best way to fix this...
I'd prefer option 2 as to me whether it's a virtual application is a deployment rather than a build issue
It would be really nice if the Azure Web App Deploy task could take care of this since it knows it's deploying a virtual application.
I'd also suggest documenting this requirement somewhere more prominently since tracking this down has taken quite a while and the behaviour is quite different to standard .NET Framework deployments.