Right now, I have a couple dotnet tool install -g ${TOOL_NAME}@${TOOL_VERSION} calls that need to be run before a dotnet restore could be executed. Currently, I use the different lifecycle phases to ensure it's not done in parallel to the dotnet restore. But technically, it would be cleaner as feature which receives the name and optionally a version or additional flags like allow-roll-forward to ensure build order.
As local tools would need a manifest and usually would just need a dotnet tool restore, I only really see global tools as use-case here.
Could this be something interesting to the general or is it more like something only I'm interested in? Because if it's not, I will just go and do the feature on a user-based repository instead for personal usage. I could also offer an PR if there's interest in this at-all. Just making sure this would make sense to go into here 😀
Right now, I have a couple
dotnet tool install -g ${TOOL_NAME}@${TOOL_VERSION}calls that need to be run before adotnet restorecould be executed. Currently, I use the different lifecycle phases to ensure it's not done in parallel to thedotnet restore. But technically, it would be cleaner as feature which receives the name and optionally a version or additional flags likeallow-roll-forwardto ensure build order.As local tools would need a manifest and usually would just need a
dotnet tool restore, I only really see global tools as use-case here.Could this be something interesting to the general or is it more like something only I'm interested in? Because if it's not, I will just go and do the feature on a user-based repository instead for personal usage. I could also offer an PR if there's interest in this at-all. Just making sure this would make sense to go into here 😀