Converted to draft so it isn't merged unintentionally.

@lewing we're seeing test failures in Components-E2E that may indicate a change in mono, are you aware of anything that could be related?

Encountered browser errors [2022-04-12T04:18:45Z] [Debug] http://127.0.0.1:37767/subdir/_framework/dotnet.7.0.0-preview.4.22208.8.c2vpcbfx9u.js 2:12646 "mono_wasm_runtime_ready" "fe00e07a-5519-4dfe-b35a-f867dbaf2e28" [2022-04-12T04:18:45Z] [Debug] http://127.0.0.1:37767/subdir/_framework/dotnet.7.0.0-preview.4.22208.8.c2vpcbfx9u.js 2:18807 "Could not find symbols file dotnet.js.symbols. Ignoring." [2022-04-12T04:18:46Z] [Severe] http://127.0.0.1:37767/subdir/_framework/dotnet.7.0.0-preview.4.22208.8.c2vpcbfx9u.js 2:19870 "Error: [MONO] * Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/interp/interp.c:3607\n\n at mono_wasm_stringify_as_error_with_stack (http://127.0.0.1:37767/subdir/_framework/dotnet.7.0.0-preview.4.22208.8.c2vpcbfx9u.js:3:19506)\n/n) at Object.mono_wasm_trace_logger (http://127.0.0.1:37767/subdir/_framework/dotnet.7.0.0-preview.4.22208.8.c2vpcbfx9u.js:3:19877)\n/n) at _mono_wasm_trace_logger (http://127.0.0.1:37767/subdir/_framework/dotnet.7.0.0-

cc/ @pavelsavara

@BrennanConroy are you thinking there's a fix for our components pipeline in the newer SDK❔

I have no idea, but it's worth trying

@lewing Any ideas why an SDK update would be causing test failures related to DateTime with Blazor-Wasm?

This is blocking #41317.

This is blocking #41317.

We have an offline thread with the runtime folks, and are working on a resolution.

Current analysis seems to point to trimming issues. The test passes in Debug but fails in Release. A difference is that the app is trimmed in release.

Can someone from the Blazor or mono team find the root cause with this new information?

Did some local investigation and it seems that typing the value has no effect on the bound field.
And it works for other types like double though.

expected = new DateTime(1980, 1, 1);
target.SendKeys(Keys.Control + "a"); // select all
target.SendKeys("01/01/1980 00:00:00\t");
Assert.Equal(expected, DateTime.Parse(target.GetAttribute("value"), CultureInfo.InvariantCulture)); // SUCCEEDS
Assert.Equal(expected, DateTime.Parse(boundValue.Text, CultureInfo.InvariantCulture)); // FAILS
Assert.Equal(expected, DateTime.Parse(mirrorValue.GetAttribute("value"), CultureInfo.InvariantCulture)); // FAILS

@vitek-karas this appears to be trimming related with the linker bump. @sebastienros verified that Debug fails with trimming and Release works without it.

@TanayParikh can you point us to where the bind code lives?

@dougbu Now that the root cause has been identified, can we just temporarily quarantine the failing tests and let the SDK update go through? This is blocking other updates.

@dougbu I can help with this one and do the quarantining if you want.

Thanks @sebastienros❕ This seems like a good idea and I'm focused on the dotnet restore mitigation.

I'm trying to investigate the test failure - but so far I burnt several hours just to build the repo... unsuccessfully for now.
If somebody know about an easier way to do this... basically I think all I need is the build output of the test in question, the msbuild binlog and at least some idea where it fails.

@vitek-karas I'm hoping someone has the information you need at hand.

More generally, we'll be interested in any problems you ran into building this repository. For example, are you hitting gaps in https://github.com/dotnet/aspnetcore/blob/main/docs/BuildFromSource.md❔

Re problems making the repo build:
Installing nodejs + yarn + JDK - not a great experience based on the docs. On Windows I was able to do all of this via winget eventually (after lot of searching) and probably a lot faster then following the various websites. On Linux it feels even worse - ended up searching how to do it via apt-get mostly.
But I must admit I never worked with nodejs and so on, so maybe this is just me doing it for the first time.

Lastly - I was trying this on Windows and Linux WSL. The WSL seems to cause issues for the Selenium based tests - I think I installed everything per the doc (but I could be wrong) and the Selenium tests were still failing for me.

I guess there's a bit of a weird dichotomy to the document - it starts explaining git in relative detail. But then the section on installing pre-reqs is often very short - especially nodejs which is basically just a link. I like that at least on Windows Java can be installed by a script - that helps a lot. Would be nice to have the same for Linux.

Very last minor nit: I use PowerShell even on Linux, but the PS scripts in the repo fail in weird ways when used on Linux (didn't investigate why). For example the activate.ps1 misbehaves - and the shell script is not a replacement since it won't do me any good when in PS.

P.S.: I find it "funny" that the repo requires two competing stacks to build (NodeJS and Java). Maybe a short sentence on what they're used for?

So I made some progress in investigating the failure. It seems there's a bug in System.ComponentModel.TypeConverter - I filed this to track that: dotnet/runtime#68651

What I don't understand is why the SDK/trimmer update triggers the bug. I can repro it without trimming, just setting UseSystemResourceKeys=true, which is the default for Blazor, triggers it.

It's possible that there's something else going on in test which hides this without trimming - not sure as I can't actually run the test locally yet. The repro in the runtime bug dotnet/runtime#68651 is me reverse engineering the IL diffs from Sebastien. I don't know what is the exact call which the test will do.

I checked the IL before and after the SDK change and while it's different, the end result should be the same, in both cases the property doesn't return (Default) as the code expects. So there must be some other difference somewhere else.

Latest Windows attempt do build the repo: running restore.cmd from root I get this:

...\aspnetcore\src\Servers\IIS\build\Build.Common.Settings(12,3): error MSB4019: The imported project "...\
aspnetcore\.tools\msbuild\16.5.0-alpha\tools\MSBuild\Microsoft\VC\v160\Microsoft.Cpp.Default.props" was not found. Conf
irm that the expression in the Import declaration "...\aspnetcore\.tools\msbuild\16.5.0-alpha\tools\MSBuild\Micro
soft\VC\v160\\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk. [...\aspnetcore\src\Serv
ers\IIS\AspNetCoreModuleV2\AspNetCore\AspNetCore.vcxproj]

No idea what I'm doing wrong :-(

@vitek-karas that last error is an indication your VS installation doesn't have everything the build needs for the native projects. Using .tools\msbuild in the path means the Arcade SDK found no VS meeting the requirements in global.json. The easiest way to solve this is w/ eng/scripts/InstallVisualStudio.ps1. Use help to decide on the right parameters for whatever you already have installed.