This will hopefully make it easier to correctly subscribe to our maestro feeds
and only pick certain platforms.
It also fixes a problem where publishing wouldn't work unless we were building
for iOS, because the code was assuming that iOS was always enabled.
Attempts to push build asset information to Maestro started failing
recently:
D:\a\1\s\xamarin-macios\packages\microsoft.dotnet.arcade.sdk\6.0.0-beta.21212.6\tools\SdkTasks\PublishBuildAssets.proj(43,5): error MSB4062: The "PushMetadataToBuildAssetRegistry" task could not be loaded from the assembly C:\Users\VssAdministrator\.nuget\packages\microsoft.dotnet.maestro.tasks\1.1.0-beta.20570.1\tools\netcoreapp3.1\Microsoft.DotNet.Maestro.Tasks.dll. Could not load file or assembly 'C:\Users\VssAdministrator\.nuget\packages\microsoft.dotnet.maestro.tasks\1.1.0-beta.20570.1\tools\netcoreapp3.1\Microsoft.DotNet.Maestro.Tasks.dll'. The system cannot find the path specified.
Commit a1d0b6eb looks like it may have broken this, as it changed the
`globalPackagesFolder` used for NuGet packages across the repo.
Looking at [PublishBuildAssets.proj][0] we should be able to set the
`$(NuGetPackageRoot)` property to the new `globalPackagesFolder` value,
fixing attempts to load `Microsoft.DotNet.Maestro.Tasks.dll`.
[0]: b8007eed82/src/Microsoft.DotNet.Arcade.Sdk/tools/SdkTasks/PublishBuildAssets.proj (L32)
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
## Problem
Template package does not appear on nuget.org correctly, as `packageType` in nupkg is set to `DotnetPlatform`.
## Solution
Disabled loading Microsoft.DotNet.SharedFramework.Sdk for template package build.
it doesn't seems to be needed and overwrites PackageType to DotnetPlatform, even though initially it is correctly set to 'PackageType'
We should now have the ability to push to the `dotnet6` feed that
contains the rest of the .NET 6 SDK Workload packages. This should help
simplify workload acquisition. The .nupkg files containing .msi the
.msi installers used for VS insertions will also now be pushed to this
feed.
Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack
Context: https://github.com/dotnet/templating/wiki
Context: https://github.com/dotnet/designs/pull/120
Fixes: https://github.com/xamarin/xamarin-macios/issues/10252
To implement templates in a .NET workload:
1. Make `.nupkg` files that follow the structure of the `dotnet new`
templating system, using `$(PackageType)` of `Template`.
2. Install the `.nupkg` files in in `dotnet/template-packs/`
3. Update `WorkloadManifest.json`, to be part of the workload:
"Microsoft.@PLATFORM@.Templates": {
"kind": "template",
"version": "@VERSION@"
}
These are a starting point, for what I would consider the minimum for
the xamarin-macios repo to provide for now:
Template Name Short Name Language Tags
-------------------------------------------- -------------- ---------- ----------------------
iOS Controller template ios-controller [C#] iOS
iOS Application ios [C#] iOS
iOS Class library ioslib [C#] iOS
macOS Application macos [C#] macOS
MacCatalyst Application maccatalyst [C#] macOS/Catalyst
tvOS Application tvos [C#] tvOS
We will probably need PM input on what the final templates will be.
To use these, you might do:
$ mkdir MyApp && cd MyApp
$ dotnet new ios
$ dotnet new ios-controller --name LoginController --namespace MyApp
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [dotnet-linker] Templateify the install logic.
* [builds] Templateify the Versions.plist install logic.
* [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform.
Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions.
* [dotnet] Templateify some build code.
In the latest .NET 6, our Workloads.targets is imported earlier in the build. This
requires a few changes, because we still need to run most of our logic later in the
process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets
property.
What we're loading as soon as possible:
* Our version information (Xamarin.Shared.Sdk.Versions.targets)
* The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets)
* The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets).
This is all information that the .NET build require early on.
Changes:
* Rename all files that are loaded early to *.props.
* Updated documentations to reflect these changes.
* Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't
used and don't contain anything useful.
* Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed
to later, because it needs TargetFrameworkMoniker set.
* [dotnet] Ship libxamarin.dylib and friends.
Add libxamarin[-debug].[a|dylib] to the NuGets.
* [dotnet] Create a DOTNET_PLATFORMS variable in Make.config.
Create a DOTNET_PLATFORMS variable in Make.config and use it everywhere
instead of the PLATFORMS variable we were defining in multiple Makefiles.
Also move the creation of the DOTNET_<platform>_RUNTIME_IDENTIFIERS variables
from dotnet/Makefile to Make.config, it'll soon be needed elsewhere as well.
* [runtime] Conditionally include bits.
* Make the contents of the DOTNET_[PLATFORMS|RUNTIME_IDENTIFIERS] variables depend on the INCLUDE_[IOS|TVOS|WATCH] variables.
This is the current structure:
Microsoft.iOS.Runtime.<rid>
└─── data
│ └─── RuntimeList.xml
└─── runtimes
│ └─── <rid>
│ │ └─── lib
│ │ │ └─── net5.0
│ │ │ │ └─── Xamarin.iOS.dll
│ │ │ │ └─── Xamarin.iOS.pdb
and likewise for tvOS, watchOS and macOS.
Also fix the nuget packaging to include the reference/implementation
assemblies in FrameworkList.xml and RuntimeList.xml.
This also requires bumping .NET to a version that supports 'net5.0'.
The actual TFM is still '.NETCoreApp,Version=5.0', it's just the short name
that has changed.
Create the various NuGet packages to support .NET 5+. The packages are
currently empty (and not very useful), but the actual content will come later.
The current set of NuGet packages are (this list is duplicated for each
platform: iOS, tvOS, watchOS and macOS):
* Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an
MSBuild Project SDK. Will eventually contain all the build logic. Might also
eventually contain other tools (mlaunch, bgen, etc.), but these might also
end up in a different package.
* Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly.
* Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files
(libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.):
The NuGets built on CI are automatically published to a NuGet feed.
The versioning for the NuGet packages required a few changes: OS bumps are now
changed in Make.versions instead of Make.config (this is explained in the
files themselves as well).
Rolf Bjarne Kvinge
Peter Collins
Vlada Shubina
Jonathan Peppers