This is the first step towards [multi-targeting support][1]. In order to
support multi-targeting, it must be possible to install several versions of
our packs simultaneously, and that also means that it becomes a lot easier to
visualize and work with the version we want to support if the packs were named
in a helpful way.
In particular, this PR changes the sdk, ref and runtime pack names to contain
the target framework + target platform version.
This will be the new names:
* iOS
* Microsoft.iOS.Sdk.net8.0_17.2
* Microsoft.iOS.Ref.net8.0_17.2
* Microsoft.iOS.Runtime.ios-arm64.net8.0_17.2
* Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.2
* Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.2
* tvOS
* Microsoft.tvOS.Sdk.net8.0_17.2
* Microsoft.tvOS.Ref.net8.0_17.2
* Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.2
* Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.2
* Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.2
* Mac Catalyst
* Microsoft.MacCatalyst.Sdk.net8.0_17.2
* Microsoft.MacCatalyst.Ref.net8.0_17.2
* Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.2
* Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.2
* macOS
* Microsoft.macOS.Sdk.net8.0_14.2
* Microsoft.macOS.Ref.net8.0_14.2
* Microsoft.macOS.Runtime.osx-x64.net8.0_14.2
* Microsoft.macOS.Runtime.osx-arm64.net8.0_14.2
There are two main benefits to renaming the packs:
* It becomes a lot easier to understand which versions we support when we
support multi-targeting. For example, say we want to support:
* net8.0-ios17.0
* net8.0-ios17.2
* net9.0-ios18.0
In this case we'd ship packs for `Microsoft.iOS.Sdk.net8.0_17.0`,
`Microsoft.iOS.Sdk.net8.0_17.2`, `Microsoft.iOS.Sdk.net9.0_18.0` (the
exact version number for each pack wouldn't be important).
If we didn't change the pack names, we'd need to track the exact versions
of the Microsoft.iOS.Sdk pack, mapping them to the correct target
framework + target platform version we want to support.
* It'll be possible to add maestro subscriptions between versions. Given the
previous example:
* net8.0-ios17.0
* net8.0-ios17.2
* net9.0-ios18.0
The branch producing `net9.0-ios8.0` could have a maestro subscription on
the branches producing `net7.0-ios17.0` and `net7.0-ios17.2`,
automatically bumping the versions whenever those branches have any
changes.
This would be rather annoying to keep track of and bump manually.
[1]: https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md
The released commit for .NET 8 isn't the exact same commit as the one
referenced here, because the build.zip file wasn't produced in that commit -
this was fixed, so it's a few commits later. There were no API changes between
these commits though, so the API references are identical.
We're going to change the pack names to support multi-targeting, so ahead
of the pack name change I'm changing the existing logic to use a variable
for the pack name in most places (this will make the rename much easier and
simpler).
These changes should have no effect by themselves.
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
When comparing with the previous commit, we can't use the TFM for the
stable version of .NET, since it may not be the same TFM used in the
previous commit.
Instead fetch the actual TFM from the checkout, and use that during the
api comparison.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Update the download of API references to:
* Use `dl.internalx.com` links instead of `bosstoragemirror.blob.core.windows.net`
links (the relative path stays the same).
* Require a GitHub PAT in order to download from dl.internalx.com. This PAT
can either be provided through a file (recommended for local use) or through
the environment.
* Document these changes.
We can only compare Microsoft.iOS.dll and Microsoft.MacCatalyst.dll when all of the following are true:
* .NET is enabled.
* iOS is enabled.
* Mac Catalyst is enabled.
So adjust (and simplify a bit) our logic accordingly.
Don't try to compare legacy vs .NET for platforms that aren't included in the build, because this happens:
> make: *** No rule to make target 'output/diff/dotnet/legacy-diff/Microsoft.macOS.Ref/ref/net6.0/Microsoft.macOS.html', needed by 'output/api-diff.html'. Stop.
We do this by not hardcoding the list of legacy platforms, but instead starting with DOTNET_PLATFORMS variable (which won't contain platforms that aren't included in the build), and then removing any .NET-only platforms (i.e. Mac Catalyst).
Also fix the `update-refs` target to not try to update refs for platforms that aren't enabled.
Fixes https://github.com/xamarin/xamarin-macios/issues/16011.
Backport of #16029
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This involved:
* Make the mono-api-info and mono-api-diff tools run with .NET 7 (instead of
requiring .NET 6).
* Make the code cope with the fact that we're comparing .NET 6 assemblies (in
a net6.0 directory) with .NET 7 assemblies (in a net7.0 directory).
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
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.
There will always be an API diff between:
* legacy Xamarin.*.dll assemblies and .NET Microsoft.*.dll assemblies.
* Microsoft.iOS.dll and Microsoft.MacCatalyst.dll
so don't bother with logic to detect empty diffs, just assume they will never be empty.
Switch to getting mono-api-[info|html] from a newly created repository we
control and where we can easily fix issues, since mono/mono isn't getting many
fixes anymore. In the past I know I've been reluctant to look at these tools,
just because of the hassle of setting things up to debug, and then the
paperwork to get the fixes in mono/mono, and then backported to the branch
where we need them.
This repo has a few other benefits:
* The tools are built using normal projects, which means they're easy to debug
in an IDE (mono/mono's code has generated project files, which used in-tree versions
of the BCL, and it got quite complex quite fast).
* One fewer dependency on the mono archive, so we're getting closed to be able
to drop it completely when we drop support for legacy Xamarin.
* #13669 is already fixed there.
* It contains a few other misc fixes.
Fixes https://github.com/xamarin/xamarin-macios/issues/13669.
When we compare assemblies with different names (such as Xamarin.iOS vs
Microsoft.iOS, or Microsoft.iOS vs Microsoft.MacCatalyst), we need to adjust
one the xml definitions to match the other with regards to the assembly name.
There was a large change to rename a lot of our Xamarin assemblies to Microsoft
ie) Xamarin.iOS -> Microsoft.iOS
There is a mismatch with some of the prerequisites in our tools/apidiff/Makefile where dependencies
are looking for ...Microsoft.iOS... but they are still named ...Xamarin.iOS...
This PR takes any remaining "Xamarin" names and changes them to "Microsoft" for all dotnet related rules.
We will also change other dotnet rules to use the new naming convention of "macOS" and "tvOS"
The only exception is to the Xamarin.PLATFORM.dll's coming from the zip - those remain as Xamarin.iOS.dll
We should expect to see the gists showing up in ApiDiffs from this PR!
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
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.
* Update README with new releases.
* [api-diff] Bump to latest stable (xcode13.1 branch) + add support for different reference api urls for legacy iOS and Mac.
Also fix make logic to only have a single rule per hash, which avoids a few
make warnings about duplicate targets.
Make seems to ignore pattern rules without a recipe, so just add an empty
recipe for this pattern rule.
Fixes:
> make: *** No rule to make target `temp/downloads/dotnet-iOS-5315390/Microsoft.iOS.Ref/ref/net6.0/Xamarin.iOS.dll', needed by `references/dotnet/Microsoft.iOS.Ref/ref/net6.0/Xamarin.iOS.xml'. Stop.
Use the jenkins script as a base to get the PAI & generator from stable
diff back to the CI. Comment is not perfect, but does provide the
required information. The comment can be improve in a later commit since
this is getting too large.
Xamarin.MacCatalyst ships a `Xamarin.iOS.dll` assembly that contains
forwarders (to `Xamarin.MacCatalyst.dll`) and stubs that throws
`PlatformNotSupportedException`.
This is used to help code compatibility between both platforms - but
that requires exposing an identical surface and the best way to ensure
this is to compare (and report) them using `apidiff`
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This is now possible since our reference is now `d16-9` which has (very
early versions of) the Xamarin.MacCatalyst (and Xamarin.iOS stubs)
assemblies.
This will become more useful when
1. bots resume the generation of commit-by-commit API diff; and
2. a real baseline is defined for the catalyst API coverage
* Add the new links to the comment done by VSTS.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The C# range expression is somewhat confusing: the lower bound is inclusive,
but the upper bound is exclusive. This means that [0..15] is 15 characters,
not the 16 characters we want here.
Fixes this during API comparison:
System.ArgumentException: Byte array for GUID must be exactly 16 bytes long.
Parameter name: b
at System.Guid..ctor (System.ReadOnlySpan`1[T] b) [0x00111] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Guid.cs:66
at System.Guid..ctor (System.Byte[] b) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/external/corefx/src/Common/src/CoreLib/System/Guid.cs:45
at Merger.Process (System.String platform, System.String path, System.String os) [0x001d1] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/apidiff/merger.cs:60
at Merger.Main (System.String[] args) [0x00002] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/apidiff/merger.cs:94
make[2]: *** [tvos-markdown] Error 1
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
TJ Lambert
Manuel de la Pena
tj_devel709
Sebastien Pouliot