[release/6.0.1xx-rc1] Update dependencies from xamarin/xamarin-android #2369
Conversation
![dotnet-maestro[bot]](https://avatars.githubusercontent.com/in/16706?s=60&v=4){kind=small}
…uild 6.0.1xx-rc1-3793f6e34c40e3aa1a00d0dbe6dd0d706283e197-1 Microsoft.Android.Sdk.Windows From Version 31.0.100-rc.1.12 -> To Version 31.0.100-rc.1.16 Dependency coherency updates Microsoft.NETCore.App.Ref,Microsoft.Dotnet.Sdk.Internal,Microsoft.Extensions.Primitives,Microsoft.AspNetCore.App.Runtime.win-x64,Microsoft.Extensions.Hosting,Microsoft.Extensions.Hosting.Abstractions,Microsoft.Extensions.DependencyInjection.Abstractions,Microsoft.Extensions.DependencyInjection,Microsoft.Extensions.Configuration.Abstractions,Microsoft.Extensions.Configuration,Microsoft.Extensions.Logging.Abstractions,Microsoft.Extensions.Logging,Microsoft.Extensions.Logging.Console,Microsoft.Extensions.Logging.Debug,Microsoft.Extensions.FileProviders.Abstractions,Microsoft.AspNetCore.Authorization,Microsoft.AspNetCore.Components.WebView,Microsoft.AspNetCore.Components.Web,Microsoft.JSInterop,Microsoft.WindowsDesktop.App.Runtime.win-x64,System.CodeDom From Version 6.0.0-rc.1.21426.8 -> To Version 6.0.0-rc.1.21451.13 (parent: Microsoft.Dotnet.Sdk.Internal
|
@Eilon is there maybe a change here for Blazor? The only change in xamarin-android here is dotnet bumps. |
|
Well that's weird... |
|
That type is generated by the Razor Source Generator. If for some reason either that type isn't being generated, or is generated at the wrong time or place, then the C# code in BlazorPage.cs won't see it. We've had that happen in WPF where XAML files couldn't see Razor-generated types: dotnet/wpf#4421 But I haven't seen that from regular C# code... |
|
Pinging @captainsafia and @NTaylorMullen in case either of you could think of some reason that a Razor-generated type from Main.razor isn't visible in this C# file BlazorPage.cs. The project file is using the Razor SDK: Maui.Controls.Sample.SingleProject.csproj. |
|
And I should add that I can't think of anything that recently changed that could affect this (famous last words, I know...). |
|
This all seems to compile fine locally with RC2 I queue'd some builds on the public pipeline to see how that goes |
|
So it's not even just this 1 project that's failing. It's the same failure in a few places that C# code is referencing Razor-generated types... but not all of them? (Though maybe it fails too soon to see all of them.) |
|
Also weird, it's net6.0 and net6.0-ios that fail. Other platforms (android, windows) seem to compile just fine? |
|
Wait, it's failing in some bizarre cross section of things... not just those platforms. |
|
In the failing compilations, I see the I assume that's correct for Razor Source Generator? It's passing in these analyzers: |
|
I think it's because you're explicitly configuring a LangVersion - . The incremental source generator requires C# 10 or newer. |
|
Ah! OK we can try to change that.... hopefully it doesn't break anything. Is 10 the default? Should we just remove LangVersion? |
|
Interestingly, there's only a few places we explicitly set 9.0. Everything else is either not set or |
|
But also it seems some of the projects don't set that. Having LangVersion=9.0 in Controls.Sample.iOS.csproj might explain why |
Razor Source Generator needs at least 10.0
|
Either way, I pushed e2ba46a so we'll see what happens... |
|
Also, one of the specific compilations that failed also had this command line arg in the failing step: |
|
In fact, nowhere in this compilation do I see anything other than LangVersion=10.0. However, there are suspiciously some places where I see RazorLangVersion=2.1 (though they are mostly 6.0), even though it's not explicitly set anywhere in the repo. |
|
Hmm... I wonder if maybe something is trying to use .NET 6 stuff on .NET 5?? I know some projects target older .NET's... and maybe they're "accidentally" getting mixed up in some bad business?? |
|
Even though the TFM in question here is always net6.0 or net6.0-something... |
|
@Eilon there's a few other spots I'm seeing it set... maui/eng/Environment.Build.props Line 31 in f0e8ea7 One of those is 'latest' but I also see others as 'preview', perhaps 'latest' still == 9.0 at this point? |
|
Hmm OK maybe latest=9.0 because preview=10.0? That's believable. |
|
There's others that are preview too in the repo still |
|
Also interestingly, according to https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version#defaults, if you use |
|
OK I pushed |
|
Also, time to go pick up kids. I will check on this later tonight. |
|
No luck. Still failing. This is failing on building the -winui.sln which may be interesting. I see the |
Context: dotnet/sdk@10efeed...454eae3 This was removed from the dotnet/sdk: <!-- Required to support incremental source generator --> <LangVersion Condition="'$(UseRazorSourceGenerator)' != '' ">preview</LangVersion> So I think we need to opt into `preview` to build with the older Roslyn in VS.
|
I was looking at the diff of the dotnet/sdk in this bump: - <!-- Required to support incremental source generator -->
- <LangVersion Condition="'$(UseRazorSourceGenerator)' != '' ">preview</LangVersion>dotnet/maui has to build with VS/.NET framework MSBuild to support WinUI (WinUI's MSBuild task assemblies are still .NET framework). I bet the VS we're building with doesn't have the latest Roslyn, and so
|
|
The other error I'm seeing (didn't fix yet): There is a change to overload resolution in the diff: The projects hitting this (a couple test projects), we might need to keep them on C# 9 and put a comment why. |
This apparently breaks NUnit `Assert.That()` calls. I could build the project locally after this change.
|
Ok, just seems like test failures now:
@Redth I don't know if we've seen those before? |
|
It's conceivable that these test failures have something to do with the |
|
The tests all pass locally... |
|
And I just realized they failed on Mac only. They passed on Windows. |
|
I'm testing my hypothesis that this has to do with whether the platform supports dynamic compiled code, per |
|
Well that's no fun, all platforms (Windows and macOS) report |
Eilon
force-pushed
the
darc-release/6.0.1xx-rc1-cd9950e4-1860-4e4e-88b6-076f82a5d302
branch
from
a39e866
to
47de1f3
Compare
|
I reverted and forced push to before my silly test. |
|
OK it does fail locally on my Mac, so that's something to look at. |
This reverts commit 85ce42d.
I think we might also be hitting some method overloading issues in these test failures: * `CanAddMultipleEventsViaMultipleConfigureLifecycleEvents` * `CanAddMultipleEventsViaBuilder` * `EventsFireExactlyOnce`
This reverts commit 90c233d.
This solves 3 test failures:
> .\bin\dotnet\dotnet.exe test src\Core\tests\UnitTests\Core.UnitTests-net6.csproj -bl
...
[xUnit.net 00:00:00.60] CanAddMultipleEventsViaMultipleConfigureLifecycleEvents [FAIL]
Failed CanAddMultipleEventsViaMultipleConfigureLifecycleEvents [10 ms]
Error Message:
Assert.Equal() Failure
Expected: 1
Actual: 0
Stack Trace:
at Microsoft.Maui.UnitTests.LifecycleEvents.LifecycleEventsTests.CanAddMultipleEventsViaMultipleConfigureLifecycleEvents() in C:\src\maui\src\Core\tests\UnitTests\LifecycleEvents\LifecycleEventsTests.cs:line 134
[xUnit.net 00:00:00.62] EventsFireExactlyOnce [FAIL]
[xUnit.net 00:00:00.62] CanAddMultipleEventsViaBuilder [FAIL]
Failed EventsFireExactlyOnce [2 ms]
Error Message:
Assert.Equal() Failure
Expected: 1
Actual: 0
Stack Trace:
at Microsoft.Maui.UnitTests.LifecycleEvents.LifecycleEventsTests.EventsFireExactlyOnce() in C:\src\maui\src\Core\tests\UnitTests\LifecycleEvents\LifecycleEventsTests.cs:line 75
Failed CanAddMultipleEventsViaBuilder [2 ms]
Error Message:
Assert.Equal() Failure
Expected: 1
Actual: 0
Stack Trace:
at Microsoft.Maui.UnitTests.LifecycleEvents.LifecycleEventsTests.CanAddMultipleEventsViaBuilder() in C:\src\maui\src\Core\tests\UnitTests\LifecycleEvents\LifecycleEventsTests.cs:line 156
Failed! - Failed: 3, Passed: 367, Skipped: 0, Total: 370, Duration: 192 ms - Microsoft.Maui.UnitTests.dll (net6.0)
…50e4-1860-4e4e-88b6-076f82a5d302
|
So what exactly "fixed" this? Did we just wait for a newer Roslyn that fixed/changed what was originally breaking this test? |
@Eilon I think there were two issues:
|
Redth
deleted the
darc-release/6.0.1xx-rc1-cd9950e4-1860-4e4e-88b6-076f82a5d302
branch
* upstream/main: (326 commits) Re-enable interpreter on blazor by default Determine size of auto cells in GridLayout correctly when views occupy same cell (dotnet#2391) [main] Update dependencies from xamarin/xamarin-macios (dotnet#2326) [Android] Fix Horizontal Scrollbar Visibility (dotnet#2374) Try start vs4mac with local dotnet (dotnet#2386) [workoad] include missing dependencies in the workload (dotnet#2281) Update project templates to work with safe characters (dotnet#2368) [release/6.0.1xx-rc1] Update dependencies from xamarin/xamarin-android (dotnet#2369) Update dependencies from https://github.com/xamarin/xamarin-macios build 20210903.3 (dotnet#2384) Bump manifest to use api 31 (dotnet#2366) BoxView Handlers (dotnet#2250) Implement IsTextPredictionEnabled in WinUI Editor (dotnet#1478) Implement PlaceholderColor property in EntryHandlers (dotnet#1513) Automated dotnet-format update (dotnet#2355) Show entire search bar by default and make it not collapse (dotnet#2351) Remove test cloud if def for now (dotnet#2350) Add support for JS root components in BlazorWebView (dotnet#2293) Set base viewmapper to work against IViewHandler (dotnet#2339) NavigationView Handler for Android (dotnet#2336) Update OutputType to WinExe on -windows (dotnet#2340) ...
This pull request updates the following dependencies
Coherency Updates
The following updates ensure that dependencies with a CoherentParentDependency
attribute were produced in a build used as input to the parent dependency's build.
See Dependency Description Format
From https://github.com/xamarin/xamarin-android