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.
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>
This includes:
* 32-bit version of Xamarin.Mac.dll and OpenTK.dll
* XamMac.dll and XamMac.CFNetwork.dll
* 32-bit versions of the runtime libraries (libxammac.a and friends).
* 32-bit version of the partial static library for Xamarin.Mac.
* Classic support in the generator.
We still ship a few Classic files so that Visual Studio for Mac continue to detect that Xamarin.Mac is installed (otherwise VSfM won't open Classic projects, which makes it impossible to use the migration wizard).
This makes our build slightly faster.
Partial fix for #6300.
This fixes an issue with the api comparison since the api comparison fails if
it detects unexpected modified files: https://github.com/xamarin/xamarin-macios/pull/6133#issuecomment-496283224.
Putting the temporary files in APIDIFF_DIR makes sure the api comparison
doesn't see those files as unexpectedly modified.
* [apidiff] Add rule to get mono-api-info.exe and mono-api-html.exe.
This fixes an issue when bumping mono: when bumping mono, the already
downloaded mono archive isn't applicable (because we've changed to the
previous commit, which has the previous mono hash, whose archive hasn't been
downloaded).
So add a rule to get mono-api-info.exe and mono-api-html.exe, by downloading
the current mono archive.
* [apidiff] Change the name of the unzip stamp and download dir to contain the hash.
This way the logic doesn't get confused when the hash changes (or there's an
old unzip stamp in the directory), and things are downloaded again as
expected.
* [apidiff] Make make not delete temporary files.
Things end up confused if temporary files have been removed by make, but our
stamp file that the temporary files are still there is present.
* [apidiff] No need to make everything depend on the bundled zip.
If everything that needs the bundled zip already depends on it.
* [apidiff] Restore original hash before calculating api diff.
This makes it less annoying when the api diff calculation changes, because
with the previous behavior they were impossible to test in a PR, since any
changes wouldn't take effect until after the PR was merged.