This project is read-only.

XmlFile not replacing existing elements when using XPath

Jul 30, 2010 at 3:35 PM

Sorry to report a bug for a feature that was added only a few hours ago, but:

In AddElement, the code doesn't check for an existing element when using an XPath.  I notice that it will indeed check and replace when the ParentElement is used, but if you use an XPath, the check isn't performed.  Is this the desired functionality?

Thanks for the great support!

Jul 30, 2010 at 3:54 PM

So it's interesting you've found this. When I was adding the InnerText feature I noticed that when using ParentElement, if the node existed then it would do nothing. That didnt seem right so I changed it to update the InnerTExt if it was found. This would not break anyone because innertext is a new property. So then I thought what about users who want to add multiple nodes that are they same? they cant, unless they switch to XPAth. I didn't change the task to allow adding multiple when using ParentElement as this may break existing users (but I would argue they are using the task badly). I thought about adding a ForceAdd property, but haven't added it (yet). Given how Xpath has been workign for the task, I couldnt stop users adding multiple nodes and just update the node found as this would break users. Again another property would be required.

How would you like / expect this to work?


Jul 30, 2010 at 4:17 PM

That's a really good point.  On the one hand, it's not really friendly to have that hidden "feature", which really only depends on the way the user uses the task.

On the other hand, there's also already ways to achieve what I'm trying to do.  I could perform a RemoveElement first.  I could also use the XmlTask to perform a transform, though I would personally see that as overkill for a simple update of an existing XML Element.

Until now, I've been using the MSBuild Community Tasks (, which are no longer supported.  There, there was an XmlUpdate task, which took an XPath (ie. "/configuration/mysection/add[@key='abc']/@value") as well as a Value.  Perhaps all that we're missing here is an Update task, in addition to the Add and Remove tasks?  It kind of seems strange to perform double-duty on the AddElement task to have it also update existing ones.  As you say, it should be possible for a user to add a second instance of an existing Element, so the only way for the task to know what the user intended, is if the user communicates it.  If they have to decide anyway, then maybe it's clearer to have a new task, which has the nice side-effect of not breaking any existing functionality for users.

Does that make sense?

Aug 3, 2010 at 7:52 AM

Do you think this is something that we might see in a future update?

Aug 3, 2010 at 8:19 AM

Yes. It will be in the next release.


Aug 27, 2010 at 7:59 AM

Will this be coming soon?

Aug 27, 2010 at 8:29 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 27, 2010 at 10:31 AM

Hi, Let me know if works for you.



Aug 30, 2010 at 11:41 AM

Works perfectly!  Thanks a million!  I can finally remove the unsupported MSBuild Community Tasks!  :)