3

I've spent the day trying to get to the bottom of an XML transformation error in Azure DevOps and I can't seem to get a handle on the problem. Locally the config transform works fine and the config transforms for the other environments that I'm deploying to are working in Azure DevOps.

The error that appears in the logs when the IIS Web App Deployment task is terminated is:

2021-02-26T15:29:49.9263250Z ##[error]Error: XML transformation error while transforming C:\...\Web.config using C:\...\Web.Live.config.

Obviously I've cut out the long file paths that Azure DevOps applies.

Further up in the IIS Web App Deployment task logs the following error appears but is not highlighted as being significant. Aster this error is logged it does appear to apply transforms, before giving the aforementioned error which terminates the process:

2021-02-26T15:29:49.9178971Z System.NullReferenceException: Object reference not set to an instance of an object.
2021-02-26T15:29:49.9180071Z    at Microsoft.Web.XmlTransform.XmlTransformationLogger.ConvertUriToFileName(XmlDocument xmlDocument)
2021-02-26T15:29:49.9180525Z    at Microsoft.Web.XmlTransform.XmlTransformationLogger.LogWarning(XmlNode referenceNode, String message, Object[] messageArgs)
2021-02-26T15:29:49.9180911Z    at Microsoft.Web.XmlTransform.Transform.ApplyOnAllTargetNodes()

I've been through the XML file and can't find any malformed XML, I've also run it through an XML validator. I've previewed the transform locally in Visual Studio 2019 Professional (possible using Slow Cheetah) and it's fine there too.

Can anyone give a pointer as to what might cause this transformation error in the pipelines?

Carpentweet
  • 309
  • 1
  • 9

2 Answers2

9

I found my answer, it was posted online on a blog by this top lad or lady.

https://tatvog.wordpress.com/2017/06/06/visual-studio-team-services-web-config-transform-error/

Edit: In case the link goes dead, the solution was as below.

I tracked that the culprit was the following transform:

<system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>

I got it to work by changing the transform to this:

<system.web>
   <compilation targetFramework="4.5" xdt:Transform="Replace">
   </compilation>
</system.web>
Carpentweet
  • 309
  • 1
  • 9
  • 1
    I had exactly that error. First page on google. Thanks SO and the community! – GELR Jan 14 '22 at 16:14
  • What if I'm targeting a different version of the framework, will this revert it to 4.5? What if I have sub-nodes in the compilation element, will this remove them all? Sorry both the answer and blog post that it's based on need more details\explanation. – mutex Feb 14 '22 at 22:22
  • @mutex, set it to the framework version that is in the web.config. – Kevin C. May 12 '22 at 12:17
1

I know this one is a bit old, but the problem could be that the VSBuild task is transforming the web.config file, and then the release pipeline is as well.

So for example, if you have a transform that removes the debug attribute, unless the VSBuild task has a TransformWebConfigEnabled=False parameter, it will transform the web.config and remove the debug attribute. When the release pipeline runs it will again try to remove the attribute, but it's already been removed, so the error is thrown.

Here's how I instruct the VSBuild task not to transform:

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)" /p:AutoParameterizationWebConfigConnectionStrings=False /p:TransformWebConfigEnabled=False'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
Jeremy
  • 44,950
  • 68
  • 206
  • 332
  • This was my issue. I as consolidating my pipelines and changing the transform to happen in the release pipeline instead in azure devops and had a stray "DevServer" build configuration set in the build. Its crazy to me that this actually fails when there are no debug attributes. – computrius Aug 01 '23 at 20:53