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
Note: affected tools are not included in the code shipping inside the SDK
Usage of deprecated cryptographic algorithms is not approved anymore,
even if not used for cryptographic purpose.
MD5 was used to create immutable GUID since it's output is 128bits which
is just what a GUID wants as it's input (16 bytes). The same can be
achieved (even if a bit slower) with a newer/longer hash function
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1128148
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.
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
TJ Lambert
Manuel de la Pena
tj_devel709
Sebastien Pouliot