Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[.NET 6] Implement API diff for our .NET assemblies #10210

Closed
5 tasks done
Tracked by #44736
rolfbjarne opened this issue Dec 4, 2020 · 2 comments
Closed
5 tasks done
Tracked by #44736

[.NET 6] Implement API diff for our .NET assemblies #10210

rolfbjarne opened this issue Dec 4, 2020 · 2 comments
Assignees
@tj-devel709
Labels
dotnet An issue or pull request related to .NET (6) dotnet-pri1 .NET 6: important for stable release enhancement The issue or pull request is an enhancement estimate-2d iOS Issues affecting iOS macOS Issues affecting macOS
Milestone
.NET 6

Comments

@rolfbjarne
Copy link
Member

rolfbjarne commented Dec 4, 2020 •
edited by tj-devel709
Loading

There are multiple parts to this:

  • Implement API diff for our .NET assemblies, like we have it for our old-style assemblies.
  • Implement an API comparison between the .NET assemblies and the old style Xamarin assemblies.
  • Implement an API comparison between iOS and Mac Catalyst API

The last part is only applicable to the first stable release, while the first part applies to any subsequent stable releases.
@rolfbjarne rolfbjarne added enhancement The issue or pull request is an enhancement macOS Issues affecting macOS iOS Issues affecting iOS labels Dec 4, 2020
@rolfbjarne rolfbjarne added this to the .NET 6 milestone Dec 4, 2020
@rolfbjarne rolfbjarne added the dotnet-pri1 .NET 6: important for stable release label Feb 3, 2021
@rolfbjarne rolfbjarne mentioned this issue Feb 9, 2021
Closed
@rolfbjarne rolfbjarne added the dotnet An issue or pull request related to .NET (6) label Mar 3, 2021
@spouliot
Copy link
Contributor

Xamarin.iOS.cs for MacCatalyst does not generate a perfect copy of what we ship with Xamarin.iOS. The only way to fix (and avoid future) breakage is to do / publish an API diff between them -> I removed the "Possibly" from above.

spouliot pushed a commit to rolfbjarne/xamarin-macios that referenced this issue Mar 19, 2021
[generate-type-forwarders] Do not generate internal stubs
f5708a8 
because this
* might need to override/subclass stuff from `Xamarin.MacCatalyst.dll` (which breaks Xamarin.iOS.cs build)
* is **not** needed for binary compatibility

Also fix some visibility issues since everything was output as `public`

More needs to be fixed but will have to wait for `apidiff` support
for Xamarin.iOS.dll (Catalyst) versus Xamarin.iOS (iOS)
xamarin#10210
@spouliot spouliot mentioned this issue Mar 19, 2021
Merged
spouliot added a commit to spouliot/xamarin-macios that referenced this issue May 12, 2021
@spouliot
[dotnet][generator] Fix creating 3rd party bindings
995d993 
Internally the generator uses `AvailabilityBaseAttribute` to make its
decisions. For `dotnet` we generated the newer `[SupportedOSPlatform]`
and `[UnsupportedOSPlatform]`.

A 3rd-party (dotnet) binding might refer to members decorated with the
newer attributes and fail the build with an error [1]. Avoiding the error
is easy (first block of the diff) but it does not make the _right_
decisions (e.g. if a member is unavailable for the platform) when
generating the code.

To fix this we need to be able to convert the new attributes into the
well know `AvailabilityBaseAttribute` subclasses. We have not spotted
such cases yet because

* the bindings pass our tests (good but extra code would not fail)
* API diff across legacy and dotnet is not yet done [2]

[1] xamarin#11497
[2] xamarin#10210
@spouliot spouliot mentioned this issue May 12, 2021
Merged
spouliot added a commit that referenced this issue May 12, 2021
@spouliot
[dotnet][generator] Fix creating 3rd party bindings (#11522)
1026b3f 
Internally the generator uses `AvailabilityBaseAttribute` to make its
decisions. For `dotnet` we generated the newer `[SupportedOSPlatform]`
and `[UnsupportedOSPlatform]`.

A 3rd-party (dotnet) binding might refer to members decorated with the
newer attributes and fail the build with an error [1]. Avoiding the error
is easy (first block of the diff) but it does not make the _right_
decisions (e.g. if a member is unavailable for the platform) when
generating the code.

To fix this we need to be able to convert the new attributes into the
well know `AvailabilityBaseAttribute` subclasses. We have not spotted
such cases yet because

* the bindings pass our tests (good but extra code would not fail)
* API diff across legacy and dotnet is not yet done [2]

[1] #11497
[2] #10210
@samhouts samhouts mentioned this issue Jul 7, 2021
Closed
32 tasks
@tj-devel709 tj-devel709 mentioned this issue Sep 30, 2021
Merged
@tj-devel709 tj-devel709 mentioned this issue Oct 25, 2021
Merged
@tj-devel709
Copy link
Contributor

My PR above applies the second half of this issue: adding the Dotnet ApiDiffs!

@ghost ghost locked as resolved and limited conversation to collaborators Apr 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@tj-devel709 tj-devel709

Labels
dotnet An issue or pull request related to .NET (6) dotnet-pri1 .NET 6: important for stable release enhancement The issue or pull request is an enhancement estimate-2d iOS Issues affecting iOS macOS Issues affecting macOS
Projects
None yet
Milestone
.NET 6
Development

No branches or pull requests
3 participants
@rolfbjarne @spouliot @tj-devel709