Weekly update…

@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.

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

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.

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'.

Blocked on dotnet/linker#3106

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?

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

Never mind, looks like the workaround is still needed

Looks like the BasePath workaround is still required

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

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

This is a known MSBuild regression dotnet/msbuild#8153

Do we have a workaround for that problem somewhere❔

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.

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.

@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

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?

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.

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.

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?

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.

🎉🎉🎉 Thanks @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.

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.