[workoad] include missing dependencies in the workload#2281
[workoad] include missing dependencies in the workload#2281Redth merged 3 commits intodotnet:mainfrom
Conversation
6ca1c49 to
5233524
Compare
|
Now
I may move these and BlazorWebView into a new |
|
Wow, lots of stuff here. I knew workloads weren't simple, but oh boy. I guess the test updates will help us catch these all sooner? I'm sure I'm guilty of most, if not all of these errors. Sorry about that. What does a new maui-blazor workload imply? It's in some sense a pretty small thing with only a few involved packages, so it isn't clear to me the cost/benefit of more smaller workloads vs. fewer slightly chunkier workloads. |
|
I made In this PR, I'm still working on this; hopefully, it's completely working soon. |
I found that using .NET 6 rc.1/rc.2 builds, if you do:
* `dotnet new maui`
* `dotnet build`
You'll get build errors unless you add the `dotnet6` feed to a
`nuget.config`:
<add key="dotnet6" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json" />
We should put these packages *inside* the workload as `library-packs`,
so this is not needed. I had to start tracking various versions of
packages through Maestro for us to be able to do this.
To further help delimit what packs are for what, I created an abstract
`maui-blazor` workload. This is a way for us to know which packs are
only needed for Blazor. These packs are still installed by default for
all .NET MAUI workloads like `maui-desktop`, `maui-mobile`, etc., but
this gives us flexibility down the road.
To verify this won't break going forward, let's use an empty
`nuget.config` before building the templates.
`dotnet new nugetconfig` outputs:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<!--To inherit the global NuGet package sources remove the <clear/> line below -->
<clear />
<add key="nuget" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
We should be able to build apps with only the packs the workload
installed or NuGet.org.
a4f799a to
5adf0b1
Compare
| <!-- dotnet/installer --> | ||
| <MicrosoftDotnetSdkInternalPackageVersion>6.0.100-rc.2.21423.2</MicrosoftDotnetSdkInternalPackageVersion> | ||
| <!-- dotnet/runtime --> | ||
| <MicrosoftNETCoreAppRefPackageVersion>6.0.0-rc.2.21420.29</MicrosoftNETCoreAppRefPackageVersion> | ||
| <!-- xamarin/xamarin-android --> | ||
| <MicrosoftAndroidSdkWindowsPackageVersion>31.0.100-rc.2.12</MicrosoftAndroidSdkWindowsPackageVersion> | ||
| <MicrosoftMacCatalystSdkPackageVersion>15.0.100-rc.1.521</MicrosoftMacCatalystSdkPackageVersion> | ||
| <!-- xamarin/xamarin-macios --> |
There was a problem hiding this comment.
I tried to put important values at the top here with comments, and alphabetically sorted the rest.
| <Dependency Name="Microsoft.Extensions.Configuration.Binder" Version="6.0.0-rc.2.21420.29" CoherentParentDependency="Microsoft.AspNetCore.App.Runtime.win-x64"> | ||
| <Uri>https://github.com/dotnet/runtime</Uri> | ||
| <Sha>91406a13fb953d6ba8a6e274e8a6f6d240ac9436</Sha> | ||
| </Dependency> |
There was a problem hiding this comment.
I don't know of a good VS Code command to sort XML elements, I just tried to put them in OK places. Things are "kind of" sorted.
There was a problem hiding this comment.
"Kind of" is good enough in my book!
| }, | ||
| "Microsoft.Maui.Graphics.Win2D.WinUI.Desktop": { | ||
| "kind": "library", | ||
| "version": "@MicrosoftMauiGraphicsWin2DVersion@" |
There was a problem hiding this comment.
This version identifier doesn't seem to match the package name, but I'm not sure what it should be because I can't seem to find the name I would "expect" it to be: MicrosoftMauiGraphicsWin2DWinUIDesktopPackageVersion
There was a problem hiding this comment.
These Microsoft.Maui.Graphics packages aren't on Maestro, they have custom property names:
I should add PackageVersion on the end of the name in this file, though to be consistent.
Co-authored-by: Eilon Lipton <Eilon@users.noreply.github.com>
Eilon
left a comment
There was a problem hiding this comment.
CI seems happy, so I say it's legit!
* 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) ...

Description of Change
I found that using .NET 6 rc.1/rc.2 builds, if you do:
dotnet new mauidotnet buildYou'll get build errors unless you add the
dotnet6feed to anuget.config:We should put these packages inside the workload as
library-packs,so this is not needed. I had to start tracking various versions of
packages through Maestro for us to be able to do this.
To further help delimit what packs are for what, I created an abstract
maui-blazorworkload. This is a way for us to know which packs areonly needed for Blazor. These packs are still installed by default for
all .NET MAUI workloads like
maui-desktop,maui-mobile, etc., butthis gives us flexibility down the road.
To verify this won't break going forward, let's use an empty
nuget.configbefore building the templates.dotnet new nugetconfigoutputs:We should be able to build apps with only the packs the workload
installed or NuGet.org.
PR Checklist
Does this PR touch anything that might affect accessibility?
No