Update off-by-default analyzers to account for rename

[captainsafia]

Closes dotnet/aspnetcore#47359.

[ghost]

Thanks for your PR, @captainsafia.
To learn about the PR process and branching schedule of this repo, please take a look at the SDK PR Guide.

[javiercn]

@ilonatommy is this something that was recently added? _framework\dotnet.timezones.blat

The PR is updating the SDK from preview1 to preview4 and we are trying to determine if there is a bug.

From my understanding, it should be ok to update the baselines as this is just an extra file. https://github.com/dotnet/sdk/blob/main/src/RazorSdk/update-test-baselines.ps1

[captainsafia]

I updated the baselines in a31a53e but happy to revert if that ends up not being necessary.

Locally, I did observe that I was still seeing test failures related to _framework\dotnet.timezones.blat after updating the baselines but we'll see if they repro in CI.

[javiercn]

@captainsafia I think looking at your commit made things clearer.

I believe @pavelsavara mentioned that this change was coming, but I'll let him confirm.

I somewhat understood the change as there was an extra file, not one less file. I believe the timezone info is now directly embedded into the wasm payload

[javiercn]

@captainsafia the "additionally" failing tests might be tests that are not using baselines, it should be fine to just "remove" the assertion on those.

[captainsafia]

@captainsafia the "additionally" failing tests might be tests that are not using baselines, it should be fine to just "remove" the assertion on those.

Quite right! Just pushed b0a0ea4 with this.

[ilonatommy]

@ilonatommy is this something that was recently added? _framework\dotnet.timezones.blat

The PR is updating the SDK from preview1 to preview4 and we are trying to determine if there is a bug.

From my understanding, it should be ok to update the baselines as this is just an extra file. https://github.com/dotnet/sdk/blob/main/src/RazorSdk/update-test-baselines.ps1

On the contrary, dotnet.timezones.blat was there since a while already. Then, this PR: dotnet/runtime#82250 removed it and moved the data to be embedded into .wasm file.

Edit:
Pavel was planning further work on this and the status is in progress, see: dotnet/runtime#82250 (comment).

[maraf]

We were waiting till the change flows into the SDK

[javiercn]

@ilonatommy @maraf just for the sake of completeness, it's correct that the file is being removed by the update, correct?

[maraf]

@ilonatommy @maraf just for the sake of completeness, it's correct that the file is being removed by the update, correct?

Yes, as Ilona mentioned, it is bundled in the wasm file. And we need to fix BlazorEnableTimeZoneSupport

[maraf]

@radekdoulik Do you have any idea why it picks emscripten 3.1.34?

https://dev.azure.com/dnceng-public/public/_build/results?buildId=218974&view=ms.vss-test-web.build-test-results-tab&runId=4098548&resultId=100001&paneView=attachments

EDIT I don't think there is or will be a working preview4 SDK build until dotnet/runtime#83998

[radekdoulik]

@radekdoulik Do you have any idea why it picks emscripten 3.1.34?

The CI is using docker images with 3.1.34. dotnet/runtime#84014 should help

[maraf]

The CI is using docker images with 3.1.34. dotnet/runtime#84014 should help

The workload manifests for 3.1.34 are packed in the SDK, althou the runtime pack expects 3.1.30

[maraf]

@captainsafia Is it possible to use preview3?

[lewing]

@dsplaisted here we're picking up emsdk packs that are ahead of what is in runtime. I think we need the rollback file sooner rather than later.

[lewing]

@radekdoulik unless we expect to have the emsdk bump merged quickly we should probably roll back the version on emsdk main to unblock things

cc @marcpopMSFT

[captainsafia]

@captainsafia Is it possible to use preview3?

Unfortunately not, this is in reaction to a change that was made to preview4.

[lewing]

I think the best move for the moment is to disable the AOT tests while we sort out how to make them work in any sane way here. This started breaking now because previously we were using much to old versions of the manifests for these tests and now the tests will pick up the very latest build of the manifest even if they haven't been integrated into their dependency which is also not correct.

[lewing]

@captainsafia the current aot errors will go away once dotnet/emsdk#325 lands and publishes to the dotnet8 feed

[captainsafia]

@captainsafia the current aot errors will go away once dotnet/emsdk#325 lands and publishes to the dotnet8 feed

OK, I can skip the tests in this PR and open a follow-up issue to revert once that change has flowed through.

[maraf]

Runtime related changes looks good to me 👍

The .blat file could also be removed from this test (but the test is not asserting anything...) https://github.com/dotnet/sdk/blob/712dfa7c9b21acda4cd4f55b02c8cb9c5200ce0e/src/Tests/Microsoft.NET.Sdk.BlazorWebAssembly.Tests/ComputeBlazorPublishAssetsTest.cs#L60-L75

We will update this test once we have a working solution

sdk/src/Tests/Microsoft.NET.Sdk.BlazorWebAssembly.Tests/WasmBuildIntegrationTest.cs

Line 236 in 712dfa7

public void Build_WithBlazorEnableTimeZoneSupportDisabled_DoesNotCopyTimeZoneInfo()

[maraf]

I'm sorry, I didn't realize the PR will merged when I add approval..
TIL about this feature

[captainsafia]

I'm sorry, I didn't realize the PR will merged when I add approval..

Ah yes, I did this intentionally as I was keen to get this change (it breaks the off-by-default support for the RequestDelegateGenerator).

Should I make a new issue to track this follow-up?

[maraf]

Should I make a new issue to track this follow-up?

@captainsafia it's ok, we'll do it once we have the solution.