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

MinVer can fail if internal item groups are already populated #217

Closed
adamralph opened this issue Apr 4, 2019 · 7 comments · Fixed by #218
Closed

MinVer can fail if internal item groups are already populated #217

adamralph opened this issue Apr 4, 2019 · 7 comments · Fixed by #218
Labels
bug Something isn't working
Milestone

Comments

@adamralph
Copy link
Owner

adamralph commented Apr 4, 2019

This is a corner case bug that will likely never be hit, but it's simple to fix.

The internal item groups used in the MinVer target, MinVerInputs, MinVerConsoleOutput, and MinVerOutputVersion, are populated using the Include attribute. This adds the specified values to the item groups. If those item groups already contain values before the MinVer target is executed, then the MinVer target can fail or produced unexpected results.

I hit this when I was putting together IdentityServer/IdentityServer4#3163 because I was using minver-cli in a target which ran before the MinVer target and I was using the same item group names to extract the console output. It's easily worked around by using different item group names, but it caused me a huge headache trying to find out what the problem was.

@adamralph adamralph added the bug Something isn't working label Apr 4, 2019
@adamralph adamralph added this to the 1.1.0 milestone Apr 4, 2019
@bording
Copy link
Collaborator

bording commented Apr 4, 2019

What are you thinking the fix for this would be? ItemGroups can have multiple items, and you add to the group by using Include to add to the group.

@adamralph
Copy link
Owner Author

@bording I think an initial

<Foo Remove="@(Foo)" />

should do it.

@bording
Copy link
Collaborator

bording commented Apr 4, 2019

Oh, so you're thinking you'd want to clear out the ItemGroup before using it? I guess that would work.

@adamralph
Copy link
Owner Author

Released in 1.1.0-beta.1.

@viceice
Copy link

viceice commented May 24, 2019

You should issue a warning, if the internal itemgroups are not empty.

If you clear them and a user is unaware of this, then it can break the build.

Or issue a error, because internal group names shouldn't be reused.

@adamralph
Copy link
Owner Author

adamralph commented May 24, 2019

@viceice thanks for chiming in. You raise a valid point, but it's not related to this change. Before this change, the values populated in the internal item groups would be merged with any existing items which would already result in misbehaviour. After this change, the values replace any existing items, as they should have done originally. The fact that didn't happen was a bug. This change brings the internal item groups into line with all the other variables that are set by MinVer in that they are now set, rather than added to.

The remaining question then, is whether MinVer should warn before setting any variable value, not just the internal item groups. To me, that feels like overkill. It's true that someone could be using variable names prefixed with MinVer for other purposes, and when they install MinVer they encounter a clash. But I think this is really an edge case not worth worrying about. If it is user code that is using those clashing variable names, they can be changed. If it is another package, well, that's a bigger problem, but again, I think it's an edge case which will likely never happen. If it ever does, then I'd be willing to revisit this.

What do you think?

@viceice
Copy link

viceice commented May 24, 2019

Ok, agree. This should hopefully never happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants