Bump SDK to 8.0.100-alpha.1.22616.4

[dougbu]

No description provided.

[dougbu]

Weekly update…

[dougbu]

@HaoK and @dotnet/aspnet-blazor-eng, could you please help w/ the errors I'm hitting in this PR❔ Looks like a few things are a bit more stringent (again). For example, from one of the Windows jobs (though the errors look consistent across the jobs)…

CSC : error AD0001: Analyzer 'ILLink.RoslynAnalyzer.DynamicallyAccessedMembersAnalyzer' threw an exception of type 'System.InvalidCastException' with message 'Unable to cast object of type 'Microsoft.CodeAnalysis.CSharp.Symbols.PublicModel.MethodSymbol' to type 'Microsoft.CodeAnalysis.ITypeSymbol'.'. [D:\a\_work\1\s\src\Components\WebAssembly\WebAssembly\src\Microsoft.AspNetCore.Components.WebAssembly.csproj]
D:\a\_work\1\s\src\Identity\UI\src\Microsoft.AspNetCore.Identity.UI.csproj(94,5): error : Missing required metadata 'BasePath' for 'D:\a\_work\1\s\src\Identity\UI\src\assets\V4\css\site.css'.

Note the errors are coming from two different projects.

[mkArtakMSFT]

@MackinnonBuck can you help unblock this PR? see @dougbu's previous comment

[MackinnonBuck]

I've added a workaround for the exception being thrown by DynamicallyAccessedMembersAnalyzer. It appears the analyzer was unhappy with the fact that we annotated a parameter of a local function with [DynamicallyAccessedMembers]. This definitely seems like a regression in the analyzer and not a misuse on our end.

That said, I don't see any problems with moving forward with my workaround - it just removes the offending parameter from the local function, so it gets captured from the containing method instead.

I can file a bug in dotnet/linker tomorrow.

[dougbu]

Is the following error something only @javiercn can help with❔ It's coming from the GenerateStaticWebAsssetsPropsFile task (note: I didn't find the 8.0.1xx version in our current SDK) and there should be no way for BasePath not to be set.

src/Identity/UI/src/Microsoft.AspNetCore.Identity.UI.csproj(94,5): error : (NETCORE_ENGINEERING_TELEMETRY=Build) Missing required metadata 'BasePath' for '/home/vsts/work/1/s/src/Identity/UI/src/assets/V4/css/site.css'.

[JamesNK]

Blocked on dotnet/linker#3106

[MackinnonBuck]

Should we revert the last commit on this PR that works around the analyzer bug, given that we're waiting for the analyzer fix to flow through anyway?

[wtgodbe]

Closing in favor of #45075, because I'm too lazy to revert the workaround 😆

[wtgodbe]

Never mind, looks like the workaround is still needed

[wtgodbe]

Looks like the BasePath workaround is still required

[wtgodbe]

Oh, never mind, that's not what the workaround was for. @MackinnonBuck looks like we still need something for:

D:\a_work\1\s\src\Identity\UI\src\Microsoft.AspNetCore.Identity.UI.csproj(94,5): error : Missing required metadata 'BasePath' for 'D:\a_work\1\s\src\Identity\UI\src\assets\V4\css\site.css'.

But we can revert the linker workaround

[javiercn]

Oh, never mind, that's not what the workaround was for. @MackinnonBuck looks like we still need something for:

D:\a_work\1\s\src\Identity\UI\src\Microsoft.AspNetCore.Identity.UI.csproj(94,5): error : Missing required metadata 'BasePath' for 'D:\a_work\1\s\src\Identity\UI\src\assets\V4\css\site.css'.

But we can revert the linker workaround

This is a known MSBuild regression dotnet/msbuild#8153

[dougbu]

This is a known MSBuild regression dotnet/msbuild#8153

Do we have a workaround for that problem somewhere❔

[MackinnonBuck]

Looks like we're getting a new failure with the updated SDK, probably caused by the introduction of dotnet/sdk@aef3f55:

.dotnet\sdk\8.0.100-alpha.1.22578.5\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ApiCompat.ValidatePackage.targets(39,5): error MSB4018: (NETCORE_ENGINEERING_TELEMETRY=Build) The "Microsoft.DotNet.ApiCompat.Task.ValidatePackageTask" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.DotNet.ApiSymbolExtensions, Version=8.0.100.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

...in addition to the existing BasePath issue. The change causing the BasePath issue has been reverted according to dotnet/msbuild#8153 (comment). However, it seems that change hasn't hit the installer yet, so we'll have to wait for a new SDK version anyway.

Let's see if both these issues are resolved automagically in the next build.

[SteveSandersonMS]

This error mentioned above:

.dotnet\sdk\8.0.100-alpha.1.22578.5\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ApiCompat.ValidatePackage.targets(39,5): error MSB4018: (NETCORE_ENGINEERING_TELEMETRY=Build) The "Microsoft.DotNet.ApiCompat.Task.ValidatePackageTask" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.DotNet.ApiSymbolExtensions, Version=8.0.100.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

... is still happening. Looks like it's due to an SDK bug - I've submitted a probable fix at dotnet/sdk#29450.

I guess we'll be blocked on merging SDK updates for another few days at least until that gets merged and a new SDK update is available.

[javiercn]

@dotnet/aspnet-build any thoughts on this error?

C:\work\AspNetCore3\.dotnet\sdk\8.0.100-alpha.1.22613.7\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.ApiCompat.ValidatePackage.targets(39,5): error MSB4062: The "Microsoft.DotNet.ApiCompat.Task.Val
idatePackageTask" task could not be loaded from the assembly C:\work\AspNetCore3\.dotnet\sdk\8.0.100-alpha.1.22613.7\Sdks\Microsoft.NET.Sdk\targets\..\tools\net8.0\Microsoft.DotNet.ApiCompat.Task.d
ll. Could not load file or assembly 'Microsoft.DotNet.ApiSymbolExtensions, Version=8.0.100.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified. Confirm t
hat the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\
work\AspNetCore3\src\Framework\App.Runtime\src\Microsoft.AspNetCore.App.Runtime.csproj]

I updated to the latest sdk locally and is still an issue

[wtgodbe]

Likely related to dotnet/sdk#29497 - could be that we won't be able to update SDK until we update TFM to net8.0, so we may need to combine this with #45475. @ViktorHofer is that an accurate assessment?

[ViktorHofer]

Likely related to dotnet/sdk#29497 - could be that we won't be able to update SDK until we update TFM to net8.0

That only applies to source-build. This specific issue was just today fixed via dotnet/sdk#29553. Sorry for the inconvenience. Please upgrade to a newer SDK that contains the fix, when one is available.

[brunolins16]

Please upgrade to a newer SDK that contains the fix, when one is available.

I just tried locally with the latest (8.0.100-alpha.1.22615.2) and the fix is not there yet. I will check again tomorrow.

[brunolins16]

The latest SDK (8.0.100-alpha.1.22616.4) contains updates from dotnet/SDK that I believe it includes the mentioned fix. Let see what we will get?

[brunolins16]

The latest SDK (8.0.100-alpha.1.22616.4) contains updates from dotnet/SDK that I believe it includes the mentioned fix. Let see what we will get?

Issue fixed, going to merge the PR.

[TanayParikh]

🎉🎉🎉 Thanks @brunolins16!

[brunolins16]

It seems this change might have caused issues in the internal pipeline.

Unhandled exception. System.NotSupportedException: Unsupported log file format. Latest supported version is 14, the log file has version 15.
   at Microsoft.Build.Logging.StructuredLogger.BinLogReader.Replay(Stream stream, Progress progress)

I am working with the team to make the tool updated.

[ghost]

Hi @brunolins16. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.