"GetPackageDirectory" task failing unexpectedly #27239
Comments
dotnet-issue-labeler
bot
added
Area-NetSDK
untriaged
|
Whatever the bug, GetPackageDirectory.ExecuteCore should catch any ArgumentException and return an error. |
|
I can see that this particular task has not been changed since 2019: |
|
Repro: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.DotNet.ILCompiler" Version="7.0.0-*" />
</ItemGroup>
</Project><?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<clear />
<add key="dotnet-public" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json" />
<add key="dotnet7" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json" />
<add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
<add key="dotnet5" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json" />
<add key="dotnet5-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5-transport/nuget/v3/index.json" />
<add key="dotnet3.1" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet3.1/nuget/v3/index.json" />
<add key="dotnet3.1-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet3.1-transport/nuget/v3/index.json" />
<add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
<add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
<add key="benchmark-dotnet-prerelease" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/benchmark-dotnet-prerelease/nuget/v3/index.json" />
</packageSources>
<disabledPackageSources />
</configuration>Console.WriteLine("Hello, World!");dotnet publish -c Release -r win-x64cc @MichalStrehovsky @jkotas who might start getting similar bug reports as it's quite common to reference ILCompiler in this way (at least that is my impression) |
|
I can repro this with the latest RC2 SDK. It didn't repro with Preview 7. I'm putting this in the 7.0 milestone. Weird the unit test in this repo doesn't catch it - it uses the same version string. @LakshanF can you have a look? |
|
I think @LakshanF is going to need to look at this. The problem seems to be in this clause from the ILCompiler targets (which seem to be brought in from the PackageReference): <ItemGroup>
<!-- If called via package instead of the SDK, update the runtime package version to match the build package -->
<_PackageReferenceExceptILCompiler Include="@(PackageReference)" Exclude="Microsoft.DotNet.ILCompiler" />
<_ILCompilerPackageReference Include="@(PackageReference)" Exclude="@(_PackageReferenceExceptILCompiler)" />
<KnownILCompilerPack Update="Microsoft.DotNet.ILCompiler" Condition="@(_ILCompilerPackageReference->'%(Identity)')=='Microsoft.DotNet.ILCompiler'">
<ILCompilerPackVersion>@(_ILCompilerPackageReference->'%(Version)')</ILCompilerPackVersion>
</KnownILCompilerPack>
</ItemGroup>specifically on the line that sets the |
|
Oops, I missed the notifications. Thanks @baronfel on your insights above, and yes, that is the part that causes a problem. On a related note, we want to discourage users specifying explicitly the package reference and have a PR, dotnet/runtime#74591, that generates a warning for such cases. For this case where the user has a floating version, I will look for a fix that gets the specific one. |
|
The fix is in the runtime repo, dotnet/runtime#74591 |
|
We are no longer hitting the issue with the fix in, closing! 🥳 |
Information
cc @danmoseley
Linked to dotnet/performance#2564
Starting late 08/15, when building for "Runtime=NativeAOT 7.0" with "Toolchain=ILCompiler 7.0.0-*", our builds started hitting "The 'GetPackageDirectory' task failed unexpectedly". This is different from behavior using the same settings the day before. We have public logs demonstrating the error: https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-performance-refs-pull-2549-merge-ada34367314d40efb9/Partition0/1/console.e9e4522d.log?helixlogtype=result and demonstrating a successful build https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-performance-refs-heads-main-0f44758c7ce64b77aa/Partition1/1/console.7e903502.log?helixlogtype=result. Looking around I noticed the task area was updated around the same time the errors started showing up in our builds (#27159). Could this potentially be related to those changes @LakshanF?
Exception/Failure
Dotnet Info
The text was updated successfully, but these errors were encountered: