The "TransformXml" task failed unexpectedly.
System.UriFormatException: Invalid URI: The URI is empty.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at Microsoft.Web.Publishing.Tasks.TransformXml.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
After much toing and froing I discovered that converting the project to .NET 4 then back to .NET 3.5 solved the problem. Intrigued, I investigated further and found the root cause in an appSetting entry (values changed in this post for obvious reasons):
<appSettings> <add key="ServiceAccountUsername" value="domain\username" /> <add key="ServiceAccountPassword" value="doLW0>`dsP1>%!a" /> </appSettings>
A quick diff against the head source control copy showed the “>” symbol had been escaped to “>”. Reverting this change immediately caused the publish process to fail again. Password changed, problem solved.
I could find absolutely zero information on the web about this error message in the context of config transformations so hopefully this post will save someone else some pain one day.






Software architect and Microsoft MVP, you’ll usually find me writing about security concepts and process improvement in software delivery.





5 comments:
Interesting, but you can't have a > in an attribute, so wasn't valid XML to begin with, right?
Absolutely Scott, this scenario arose from the password being generated by network admins and by good luck rather than good management, never had a problem until config transformations came along. Interesting indeed.
I think the point was that you need to escape the > to >, since it isn't valid XML otherwise. The > will be read as the correct character.
Absolutely Scott, this scenario arose from the password being generated by network admins and by good luck rather than good management, never had a problem until config transformations came along. Interesting indeed.
I think the point was that you need to escape the > to >, since it isn't valid XML otherwise. The > will be read as the correct character.
Post a Comment