Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Make error message more helpful when TaskItem.ItemSpec is not set #10660

Open
MangelMaxime opened this issue Sep 13, 2024 · 4 comments
Labels
Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. Documentation Issues about docs, including errors and areas we should extend (this repo and learn.microsoft.com) Feature Request Priority:3 Work that is nice to have triaged

Comments

@MangelMaxime
Copy link

Summary

Hello,

Improve error message if ItemSpec is missing on a TaskItem

Background and Motivation

When creating a custom MSBuild task, it took me several hours to figure out why I was getting this error:

error MSB4028: The "EasyBuild.PackageReleaseNotes.Tasks.GetCurrentReleaseTask" task's outputs could not be retrieved from the "CurrentRelease" parameter. Parameter "includeEscaped" cannot have zero length.

The reason was that I didn't set the TaskItem.ItemSpec value.

Proposed Feature

Improve the error message to mention that ItemSpec should be set.

The "EasyBuild.PackageReleaseNotes.Tasks.GetCurrentReleaseTask" task's outputs could not be retrieved from the "CurrentRelease" parameter. Please set the value of ItemSpec, in your task.

Alternative Designs

Another solution would be to change the constructor of TaskItem to take a mandatory ItemSpec value, but I suspect it would be too big of a breaking change.

@baronfel
Copy link
Member

I think this could be solvable by introducing a more specific error message here - right now we have a generic 'could not bind property' message, but for something as important as the Identity/ItemSpec it makes sense to have a more directed message.

@baronfel baronfel added the Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. label Sep 13, 2024
@rainersigwald
Copy link
Member

@MangelMaxime can you confirm that you called new TaskItem() (the parameterless constructor)?

We should document that that is not ever intended to be called in normal code, it's just there as a trap :(

@MangelMaxime
Copy link
Author

@rainersigwald

This is indeed what I am doing:

this.CurrentRelease <- TaskItem()
this.CurrentRelease.ItemSpec <- version.Version.ToString()
this.CurrentRelease.SetMetadata("Version", version.Version.ToString())

Based on your message, I suppose TaskItem have other constructors, but I didn't think to check for them. Because it didn't occurred to me that a "trap constructor" would exist 😅

@rainersigwald
Copy link
Member

Yeah that's completely fair!

I'd recommend using TaskItem(string itemSpec, IDictionary itemMetadata), or new TaskItem(string) and then set metadata.

. . . now we should make the docs say the same. And maybe even hide that "so this type is COM-createable" ctor from IntelliSense or something so it's less tempting?

@maridematte maridematte added Documentation Issues about docs, including errors and areas we should extend (this repo and learn.microsoft.com) Priority:2 Work that is important, but not critical for the release labels Sep 24, 2024
rainersigwald added a commit to rainersigwald/msbuild that referenced this issue Sep 27, 2024
The doc comment mentioned that the parameterless
constructor existed only for COM but it was still
easy to find, causing problems like dotnet#10660. Hide
it from IDE completion and extend the comment.
YuliiaKovalova pushed a commit that referenced this issue Oct 2, 2024
The doc comment mentioned that the parameterless
constructor existed only for COM but it was still
easy to find, causing problems like #10660. Hide
it from IDE completion and extend the comment.
@maridematte maridematte added Priority:3 Work that is nice to have triaged and removed Priority:2 Work that is important, but not critical for the release labels Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. Documentation Issues about docs, including errors and areas we should extend (this repo and learn.microsoft.com) Feature Request Priority:3 Work that is nice to have triaged
Projects
None yet
Development

No branches or pull requests

4 participants