[Question]: Custom Task Logging Standard Practices

[LostTime76]

I am working on building several custom tasks and am attempting to get familiar with the provided interfaces. Maybe this has been asked before, but I have done a bit of research and can't come up with a good answer.

What are standard practices for using properties and task items within a custom task in regards to invalid data? The reason I am asking is that when I am parsing input property / item metadata strings and encounter errors, I would like to generate a useful error containing line & column information of the offending XML nodes. The task Log functions provide overloads for providing all sorts of information; however, how does one correlate a task property or item defined in an item group (TaskItem) to its corresponding XML node with line + column?

As it stands, the logging interface seems only useful for high level error messages that can't easily direct a user to an offending file, line, and column.

1. Is it expected to only log high level errors that originate in .props / targets files down in nuget packages and let the users fend for themselves to figure out what project file of theirs is causing the issue?
2. For invalid data, do we simply fallback to a known good default and silently ignore / don't tell the user there was an issue?
3. Do we try and search the BuildEngine XML project tree ourselves and try to correlate the offending items / properties? I don't even know how you would do that, because the only thing available it seems is ProjectFileOfTaskNode, which points to the literal file containing the task, which does not correspond to the file of the project being built on the command line.

[LostTime76]

Looking at this dumb example, the built in tasks do not even point me to the line & column. They do however seem to have access to the actual project file that is the parent of the build. I mean.. sure, an end user has enough information to say: "Hey, there is some string in one of my project files called 'adls...', I can do a search for that and find the problem. Similarly, any error that a custom task produces will ultimately have the key offending string that could be searched for by a user in their tree of project files.

Is this just the accepted mindset?

[JanKrivanek]

It's definitely a good practice to validate inputs and bail out as early as possible (e.g. for derivatives of ToolTask you can override ValidateParameters for such purpose, in other tasks you can follow the same pattern).

Unfortunately the DOM information is not available at the time of task execution, many of it is not even available during the evaluation - as it is optimized for the happy path execution. So the standard practice is to log whatever you have (e.g. "Task xyz encountered invalid value of property abc: 'x:\y\z' - path does not exist.") - users than can use logs (preferably binlogs) to find the source of the problem. The input can be produced by another task, or reassigned on various places - so a location might not be always helpful - sometimes it can be even misleading.

Would you still want to dig for location information and present that to users (at expense of some extra processing time) – than probably Project (you can construct from just a path as it will use default tools version and global props from the given project – most often this is what you need) can be the most straightforward way – it will construct and evaluate project representation with full DOM (so you get locations, even for all the imported stuff).