Fix path to TarTool in Sign.proj#15299
Conversation
| <_DotNetCorePath>$(DotNetTool)</_DotNetCorePath> | ||
| </PropertyGroup> | ||
|
|
||
| <!-- Keep TarToolPath TFM in sync with TarTool project TFM. --> |
There was a problem hiding this comment.
ok as a quick fix but nobody will remember to update this place in the future.
What about doing something like:
<ItemGroup>
<_TarToolPath Include="$(NuGetPackageRoot)microsoft.dotnet.tar\$(MicrosoftDotNetSignToolVersion)\tools\net*\any\Microsoft.Dotnet.Tar.dll" />
</ItemGroup>There was a problem hiding this comment.
I would suggest logging an error/warning if tool is not found. Right now, it fails silently.
There was a problem hiding this comment.
I think that would include the net472 one as well. Arcade continues to have a few hardcoded TFMs, i.e. in #15221.
This is the only PackAsTool component that is directly referenced in Arcade. @ellahathaway / @mmitche would it make sense for SignTool to redistribute the TarTool and optionally reference it as a classlib?
There was a problem hiding this comment.
Alternatively, it should be possible to save the TFM in Arcade's generated DefaultVersions.Generated.props file and then read from that here.
There was a problem hiding this comment.
I have a fix for the exit non-zero case in a local branch that should be up soon. That said, I don't think TarTool is actually in use. On framework it just bails:
https://github.com/dotnet/arcade/blob/main/src/Microsoft.DotNet.Tar/Program.cs#L4-L9
And in signtool, we only use tartool on framework:
I will problaby rip it out.
There was a problem hiding this comment.
I think that would include the net472 one as well.
For the record it wouldn't since we only pack it as a tool in netcore.
|
Merging to unblock the broken scenario. Filed #15300 |
Regressed with e0270d6
I verified that there is no hardcoded path to any other PackAsTool asset.