This has been bothering me for a while... the symptom is that the build just
hangs at the end. Curiously it's never happend on the bots, only locally.
1. It only happens when using parallel make. When using parallel make, make is
in a jobserver mode, where sub-makes are controlled using a pair of file
descriptors inherited by the sub-makes. A consequence of this algorithm is
that the controlling make process will wait until all inherited file
descriptors have been closed before it will realize that all its sub-makes
have finished.
2. 'dotnet pack' will build the corresponding project, and that might start a
background compiler server.
3. This background compiler server does not seem to close any file descriptors
it inherits.
4. The background compiler server does not necessarily exit by the time `make`
is done.
5. The result is that `make` things there are still sub-makes doing stuff,
because there are inherited file descriptors still open.
6. Killing the compiler server (in another terminal for instance) will make
make realize it's done (and the hang is resolved).
So I'm applying the last point: shutting down the compiler server after
packing all the .NET NuGets.
Fixes https://github.com/xamarin/xamarin-macios/issues/13355.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
This way we don't have to update the runtime identifier validation when we add
support for new runtime identifiers.
We'll also have an item group that lists the valid runtime identifiers, which
is making it possible (although the item group is currently private) to query
the valid runtime identifiers (which is something the IDEs have expressed
interest in).
It appears that the package IDs for the manifests retain the main .NET version band, such as 100 and 200, and the packs use the full version of 101 or 203.
This PR just uses the version band for the manifest packages.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update dependencies from https://github.com/dotnet/installer build 20211111.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21552.8 -> To Version 6.0.101-servicing.21561.4
* Update dependencies from https://github.com/dotnet/installer build 20211112.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21552.8 -> To Version 6.0.101-servicing.21562.12
* [dotnet] Use X.Y.Z00 as the version band for the sdk-manifests path.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle.
This makes sure that we're always using the latest BCL.
Some accurate build massaging was needed, because:
* To build the prebuilt app we need the iOS workload installed (into our build-local
.NET installation).
* The iOS workload contains the Microsoft.iOS.Windows.Sdk pack.
* The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app.
Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack
is only required on Windows, which means we can break this circular reference by:
* Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately
it seems we have to list the exact runtime identifiers for the platforms where
to install the pack, so we can't do something like "win-*", but new variations
of the "win-*" runtime identifier shouldn't show up all that often).
* Build the prebuilt app on macOS.
This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS
workload locally.
The .NET build order is now:
* Build general sdk, runtime and ref packs for .NET.
* Build the prebuilt app.
* Build the Microsoft.iOS.Windows.Sdk pack.
Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
* Update dependencies from https://github.com/dotnet/installer build 20211022.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.1
* Update dependencies from https://github.com/dotnet/installer build 20211022.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.16
* Update dependencies from https://github.com/dotnet/installer build 20211023.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21523.8
* Update dependencies from https://github.com/dotnet/installer build 20211024.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21524.1
* Add a dependency to Microsoft.NETCore.App.Ref.
That way we match what XA did here: 16c1226dde
It also makes Maestro update our NuGet.config for us, which additional feeds we seem
to need to build.
* [dotnet] Use all the sources in the NuGet.config when installing workloads.
* Update dependencies from https://github.com/dotnet/installer build 20211025.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21525.3
* Add dependency on Microsoft.AspNetCore.App.Ref.
* Update dependencies from https://github.com/dotnet/installer build 20211026.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21526.10
* [tests] Disable the implicit FSharp.Core reference.
Fixes this:
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: Unable to find a stable package FSharp.Core with version (>= 6.0.1)
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 792 version(s) in dotnet-tools [ Nearest version: 6.0.2-beta.21519.1 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 46 version(s) in dotnet-public [ Nearest version: 6.0.0 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in xamarin-impl
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-2
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-4
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-5
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in Dotnet arcade
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in dotnet6
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in macios-dependencies
* [tests] Use a specific FSharp.Core version.
* Update dependencies from https://github.com/dotnet/installer build 20211027.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21527.11
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update vs-insertion-prep.yml
* Remove filters from symbol package download as well
* [temp] Changes for testing
* Shorten manifest name
* Shorten manifest name take 2
* Add ComponentResources and WorkloadPackages for tvOS and macOS
* Don't shorten MacCatalyst name, version string replacement should suffice
* Revert "Don't shorten MacCatalyst name, version string replacement should suffice"
This reverts commit d1c1d1d89d.
* Replace long macOS versions in .msi files
* Shorten tvossimulator msi names
* Test with real signing
* Revert testing changes
* Enable tests
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Context: https://github.com/dotnet/sdk/pull/19596
Context: https://github.com/xamarin/xamarin-android/pull/6184
If we use the version number string of `**FromWorkload**`, then our
runtime packages don't need to be resolved from a NuGet feed. They can
be resolved from the `dotnet/packs` directory.
This completely eliminates the need for a `NuGet.config` file when
building a .NET 6 app with a local build of xamarin-macios.
You will no longer need a feed such as:
<add key="local-dotnet-feed" value="~/src/xamarin-macios/_build/nuget-feed" />
To further clean things up, I removed the need for:
* Any NuGet feed named `local-dotnet-feed`
* `$(DOTNET_FEED_DIR)`
* Generation of `dotnet/Workloads/NuGet.config`
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5074495&view=logs&j=f8a716f9-5318-5935-19a4-149a64409b96&t=773a1aad-99f2-5f0b-eafa-0deb88171543
Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366309
Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366310
Commit 9dbf451d added files required to support Hot Restart in .NET 6
packages, however it did not update SignList.xml to also include these
new file additions. This caused .nupkg signing issues:
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : Unknown assemblies:
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\BouncyCastle.Crypto.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\bz2.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\getopt.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\ideviceactivation.dll;
...
Fix signing by listing all new content that should be skipped or signed
with first/third party certs.
Additionally, content in nested .zip files also needs to be signed. I've
added a couple of targets to SignList.targets to unzip and rezip these
files before and after individual file signing runs.
* Add support for 'dotnet publish'.
* Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild
property to specify the resulting .pkg path, to reflect the existing
'IpaPackagePath' (for iOS and tvOS).
* Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever
used this...
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
* [dotnet] Add support for implicit namespace imports. Fixes#12084.
Also update our templates to remove any using statements for implicitly imported
namespaces.
Fixes https://github.com/xamarin/xamarin-macios/issues/12084.
* [monotouch-test] Fix compilation error due to implicit namespace causing type conflict.
Fixes these errors:
xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
* Update dependencies from https://github.com/dotnet/installer build 20210722.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21370.12 -> To Version 6.0.100-rc.1.21372.2
* [dotnet] Work around problem where the local .NET install contains an invalid workload.
We work around it by deleting the invalid workload.
* [dotnet] Fix merge failure - don't reference workloads that don't exist anymore.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Context: xamarin/yaml-templates#117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the +sha.commit metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the xamarin-impl feed.
The new SignList.xml file is required for our NuGet signing templates.
The new xamarin-workload.props file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a manual validation task. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
Commit 09f911b missed adding the
PR build check condition to a step in sign-and-notarized.yml, causing
PR builds from forks to fail. We can fix this by adding in the missing
condition.
Context: https://github.com/xamarin/yaml-templates/pull/117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the `+sha.commit` metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the `xamarin-impl` feed.
The new `SignList.xml` file is required for our NuGet signing templates.
The new `xamarin-workload.props` file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a [manual validation task][0]. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
[0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation?view=azure-devops&tabs=yaml
Context: https://github.com/xamarin/xamarin-android/pull/6045
We are aiming to simplify the .NET workload ids to short names like:
dotnet workload install maui
dotnet workload install android
dotnet workload install ios
dotnet workload install maccatalyst
dotnet workload install macos
dotnet workload install tvos
Updated the workload ids here, as well as the `.stamp-install-workloads`
make target.
Other changes:
* Updated descriptions to match Android. Still waiting on an *official*
description we should be using for each workload.
* Fixed trailing `,` that showed up as JSON errors in VS Code.
* Update dependencies from https://github.com/dotnet/installer build 20210606.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21306.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210613.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21313.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210615.23
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21315.23
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Fix custom step order
In response to https://github.com/mono/linker/pull/2082
* Update dependencies from https://github.com/dotnet/installer build 20210620.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21320.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21317.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210621.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21321.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21317.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Remove unnecessary workaround.
* [dotnet] Update our code to get the path to the AOT compiler. Fixes#11905.
* [dotnet] Remove another workaround for runtime packs doing the wrong thing.
* Update dependencies from https://github.com/dotnet/installer build 20210622.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21322.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210622.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21322.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210623.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21323.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210623.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21323.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210624.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21324.6
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet] Install the microsoft-net-runtime-maccatalyst workload as well.
* Update dependencies from https://github.com/dotnet/installer build 20210625.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21325.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210626.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21326.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21322.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Sven Boemer <sbomer@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Having .NET enabled with the windows-specific parts disabled is not a
scenario tested on CI (where we've always enabled both). This means it's
prone to bitrotting.
* It's another configuration to keep track of and make work locally.
* It doesn't work right now anyway.
So just always enable the windows-specific parts of the .NET build, if the
.NET build is enabled.
We randomly run into a NuGet restore failure, which breaks the build, and is
quite annoying.
This might be due to a problem with multiple simultaneous restores, so this is
an attempt to first restore the packages we need, in a single serialized
restore, and once that's done we can process everything else in parallel.
Ref: https://github.com/xamarin/maccore/issues/2427
Ref: https://github.com/NuGet/Home/issues/10935
NuGet doesn't support preserving the executable bit for files in *.nupkgs
(which are just zip files), so .NET implemented a [temporary
workaround](https://github.com/dotnet/sdk/pull/17299) for workload installs,
where they hardcoded files that should be executable.
This isn't really sustainable, and they'll remove their workaround, so we need
to use their supported method of specifying the file permissions: a
data/UnixFilePermissions.xml file.
Fixes https://github.com/xamarin/xamarin-macios/issues/11860.
* [tests] Augment the .NET unit tests to verify that more runtime identifiers build.
* [dotnet] Show a better error if the AOT compiler doesn't exist.
* [dotnet] Use the official path for the AOT compiler.
* [dotnet] Use platform-specific templates for WorkloadManifest.json.
* [dotnet] Generate the workload targets before the nupkgs.
This avoids a random build failure when doing parallel make.
* [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests.
* [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono.
* [dotnet] Move the workloads into a common subdirectory.
Also delete the watchOS workload, we're not shipping it for now.
* [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones.
* Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one).
* Stop installing workloads from builds/
* Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'.
* Fix makefile logic.
* Another tweak.
* [dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100
Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125
Context: https://github.com/xamarin/xamarin-android/pull/5898
The `$(PackageId)` of our workload `.nupkg` needs to be:
Microsoft.NET.Sdk._platform_.Manifest-6.0.100
While the `$(PackageVersion)` remains the same as before.
The layout on disk will change to:
dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk._platform_\
WorkloadManifest.json
WorkloadManifest.targets
Note that `.Manifest` and `-6.0.100` are not in the folder name on disk.
At the same time, let's also update the `version` in
`WorkloadManifest.json` so it contains the proper version for our
workload. This used to not be possible because `version` was a `long`,
but it now is a `string` where we can put our version.
* Use $(DOTNET6_VERSION_BAND)
* Pass in -p:VersionBand to 'dotnet pack'
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
Rolf Bjarne Kvinge
Manuel de la Pena
Peter Collins
Matthew Leibowitz
dotnet-maestro[bot]
Jonathan Peppers