Projects which were multitargetd to support .NET 6 have been updated to
target `net6.0` instead of `netcoreapp3.1`. CI has been updated to
install .NET 6 preview 3 instead of .NET 5.
* Bump to xamarin/xamarin-android-tools/main@683f375
Changes: c5732a0e...683f3750
The `dotnet_create_msi` job has been updated to publish information
about Android .NET 6 .nupkg files to the dotnet Maestro server.
With this data being published, the `darc` tool can now be used to
manage an Android .NET 6 product dependency:
darc add-dependency -n Microsoft.Android.Sdk.Windows -t product -r https://github.com/xamarin/xamarin-android -v 1.2.3
darc update-dependencies --channel "General Testing Internal"
Looking up latest build of https://github.com/xamarin/xamarin-android on General Testing Internal
Updating 'Microsoft.Android.Sdk.Windows': '1.2.3' => '11.0.200-ci.publish-bar-manifest.197' (from build 'publish-bar-manifest-41c7adffb2669c313e96607f98f8ab05c820e56f-1' of 'https://github.com/xamarin/xamarin-android')
For dependency updating to work, we must configure "default channel"
associations for all xamarin-android branches that other products may
be interested in tracking. The `darc` tool can be used to do this
manually:
darc add-default-channel --channel ".NET 6" --branch "main" --repo https://github.com/xamarin/xamarin-android
This default channel configuration ensures that all new builds produced
by our main branch will be associated with the .NET 6 channel. Android
consumers can then update to the latest build available from main with
the `update-dependencies` command:
darc update-dependencies --channel ".NET 6"
Context: ea609b8e03/Documentation/Darc.md
The dotnet core engineering group has some dependency management
tooling known as `darc` that we'd like to adopt. Integrating this
tooling into the build system will make it easier to stay up to date
with the latest .NET 6 SDK changes.
Many dotnet repos use a [publishing workflow][0] that will push build
artifact data to a central location known as the
"Build Asset Registry". This data includes a "[Channel][1]"
association, which is the key to dependency updating. Local updates
and automatic update "Subscriptions" compare the version files in a
given repo against the product versions available in the channel that
you are interested in.
We hope to be able to publish Xamarin SDK build information to this
central registry in the near future, so that other products can take
a dependency on us as needed (dotnet/maui for instance).
The `darc` tool looks for four different files in a repo when adding
a dependency or when checking for an update:
* `eng/Version.Details.xml`
* `eng/Versions.props`
* `global.json`
* `nuget.config`
Both of the `Version*` files present in the `eng` folder are updated
when a new dependency is available.
To work with `darc` locally you will need to [install][2] the `darc`
global tool, join the `arcade-contrib` GitHub team, and configure your
auth settings.
To add a new dependency, use the [`darc add-dependency`][3] command:
darc add-dependency -n Microsoft.NetCore.App.Runtime.android-arm64 -t product -v 6.0.0-preview.2.21154.6 -r https://github.com/dotnet/runtime
To update all dependencies, use the [`darc update-dependencies`][4]
command:
darc update-dependencies --channel ".NET 6"
To configure automatic updates, use the [`darc add-subscription`][5]
command to enroll a target repo/branch into updates from a particular
channel:
darc add-subscription --channel ".NET 6" --source-repo https://github.com/dotnet/installer --target-repo https://github.com/xamarin/xamarin-android --target-branch main --update-frequency everyWeek --standard-automerge
Once a subscription is configured, [a pull request][6] will be
created automatically by the dotnet Maestro bot when dependency
updates are available.
~~~
This PR also contains a bump to .NET 6.0.100-preview.3.21168.18.
Changes: 19e22a76...823c1dfce
The .NET 6 `.apkdesc` files have been updated accordingly. It seems
that `System.Private.CoreLib.dll` grew in size, however reductions in
native libraries/etc. results in an overall smaller package sizes.
Simple XA:
-"PackageSize": 2889606
+"PackageSize": 2877318
XF/XA:
-"PackageSize": 8746124
+"PackageSize": 8733836
[0]: 681511f2f6/Documentation/CorePackages/Publishing.md (what-is-v3-publishing-how-is-it-different-from-v2)
[1]: https://github.com/dotnet/arcade/blob/main/Documentation/BranchesChannelsAndSubscriptions.md#branches-channels-and-subscriptions-explained
[2]: ea609b8e03/Documentation/Darc.md (setting-up-your-darc-client)
[3]: ea609b8e03/Documentation/Darc.md (add-dependency)
[4]: ea609b8e03/Documentation/Darc.md (update-dependencies)
[5]: ea609b8e03/Documentation/Darc.md (add-subscription)
[6]: https://github.com/xamarin/xamarin-android/pull/5744
Context: 0342fe5698
Now that `Xamarin.Android.Build.Tasks.csproj` is a short-form project
(03743f32a), add a dependency on the [`Microsoft.DotNet.Arcade.Sdk`][0]
NuGet package, and switch to using the
[`$(GenerateResxSource)` mechanism][1] instead of using
`%(EmbeddedResource.Generator)`=`ResXFileCodeGenerator`, which only
updates `Resources.Designer.cs` when using the Visual Studio IDEs.
For this initial use of `Microsoft.DotNet.Arcade.Sdk`, import only
`..\tools\BuildTasks.props` and `..\tools\GenerateResxSource.targets`.
Avoid importing the full `Sdk.props` and `Sdk.targets` for now because
those files have other consequences that aren't desired at this time.
For example, `Sdk.props` indirectly imports `ProjectDefaults.props`,
which sets `$(DebugType)`=`embedded` by default, and
`[assembly:AssemblyVersion("42.42.42.42")]` is added.
An advantage of `$(GenerateResxSource)`=True compared to
`ResXFileCodeGenerator` is that contributors no longer need to worry
about updating `Resources.Designer.cs` when updating `Resources.resx`.
This is especially helpful for contributors who use an editor other
than Visual Studio (macOS & Windows), because it means they no longer
need to hand-edit the `Resource.Designer.cs` file to match the format
that `ResXFileCodeGenerator` generates on Windows.
The generated file
`obj/$(Configuration)/Xamarin.Android.Tasks.Properties.Resources.cs`
has essentially the same setup as the previous `Resources.Designer.cs`.
The properties are still `internal` and still include `<summary/>`
comments to surface the non-localized messages in IntelliSense, and the
file is still updated by a design-time build any time the `.resx`
file changes.
One difference is that the new generated `.cs` file is not shown in the
Solution Explorer because it's located in `obj/`. If any contributors
were previously using `Resources.Designer.cs` as a starting place to do
"find all references" on the property names, they would now need to open
the generated file from the `obj/` directory instead.
[0]: 0940dc72b8/src/Microsoft.DotNet.Arcade.Sdk
[1]: c6f24c0d12/Documentation/ArcadeSdk.md (generateresxsource-bool)
Remove `build-tools/create-packs/global.json` and have a single
`global.json` file in the root. This allows us to remove the version
number for `Sdk="Microsoft.Build.NoTargets"` in several files.
We weren't able to do this in commit 079197ac because the extra
`global.json` file that took precedence over the one in the root.
Context: https://github.com/xamarin/xamarin-android/pull/5064
Xamarin.Android has many "projects" that are `.csproj` files, but do
not actually compile a managed assembly. Instead, their `Build` and
`Clean` targets are overridden to perform other tasks, like compile
Java code.
When using a `Directory.Build.props` file to add a NuGet to all
projects, as is done in PR #5064, these projects fail to build due to
a NuGet error:
…/Microsoft.NuGet.targets(186,5): error : Object reference not set to an instance of an object [/Users/builder/azdo/_work/3/s/xamarin-android/src/r8/r8.csproj]
…/Microsoft.NuGet.targets(186,5): error : at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.IsFileValid (System.String file, System.String expectedLanguage, System.String unExpectedLanguage)
…/Microsoft.NuGet.targets(186,5): error : at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.TryGetFile (System.String packageName, System.String packageVersion, System.String packageRelativePath, System.String file, System.String& path)
…/Microsoft.NuGet.targets(186,5): error : at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.GetAnalyzers (Newtonsoft.Json.Linq.JObject lockFile)
…/Microsoft.NuGet.targets(186,5): error : at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.ExecuteCore ()
…/Microsoft.NuGet.targets(186,5): error : at Microsoft.NuGet.Build.Tasks.ResolveNuGetPackageAssets.Execute ()
Nowadays there is a better solution for these types of projects which
produces more correct projects with fewer side-effects:
The [`Microsoft.Build.NoTargets` SDK][0].
Convert these projects to SDK-style projects using the
`Microsoft.Build.NoTargets` SDK.
Normally, using this SDK would require specifying the package version
in each `<Package/>` element:
<Project Sdk="Microsoft.Build.NoTargets/2.0.1">
Add a `global.json` file so that the `/Project/@Sdk` attribute can
*lack* the version number -- `global.json` provides the version --
allowing `Microsoft.Build.NoTarets` projects to uniformly use the
same package version:
<Project Sdk="Microsoft.Build.NoTargets">
This supersedes some of the changes in:
- https://github.com/xamarin/xamarin-android/pull/4950
- https://github.com/xamarin/xamarin-android/pull/4973
[0]: 59125812d1/src/NoTargets
Peter Collins
Brendan Zagaeski
Jonathan Peppers
Jonathan Pobst