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.

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

[iOS] [.NET 8] Binding library source generator does not use interface for protocols #19612

Closed
Sleeckx opened this issue Dec 8, 2023 · 3 comments · Fixed by #19619
Closed
Labels
bug If an issue is a bug or a pull request a bug fix generator Issues affecting the generator regression The issue or pull request is a regression
Milestone

Comments

@Sleeckx
Copy link

Sleeckx commented Dec 8, 2023

Hello,

I'm trying to update my iOS binding library from .NET 7.0 to 8.0, but I believe the code behind source generator is not generating the correct code. When I define a protocol, it's not using the generated interface causing the object to try to inherit from both the NSObject and the protocol class. This results in compiler error CS1721 (cannot have multiple base classes).

This was working correctly in .NET 7.0, could I be missing a breaking change?

Steps to Reproduce

Create a new binding library and add the following code to the ApiDefinition.cs in a namespace of your choosing.

using System;
using ObjCRuntime;
using Foundation;
using UIKit;

[Protocol]
[BaseType(typeof(NSObject))]
public interface ReaderProtocol
{
    // @required -(NSString *)firstName;
    [Abstract]
    [Export("firstName")]
    string FirstName { get; }
}

// @interface Reader : NSObject <ReaderProtocol>
[BaseType(typeof(NSObject))]
public interface Reader : ReaderProtocol
{
    // -(id)initWithPreferredReader:(NSString *)name;
    [Export("initWithPreferredReader:")]
    IntPtr Constructor(string name);
}

Expected Behavior

The generated Reader.g.cs file should have a Reader class with the following signature (net7.0-ios behavior):

[Register("Reader", true)]
public unsafe partial class Reader : NSObject, IReaderProtocol {
...
}

Actual Behavior

The generated Reader.g.cs file contains a Reader class with the following signature (net8.0-ios behavior):

[Register("Reader", true)]
public unsafe partial class Reader : NSObject, ReaderProtocol {
...
}

This causes the compiler to throw error CS1721 "Class 'Reader' cannot have multiple base classes: 'NSObject' and 'ReaderProtocol'.

Environment

Version information

Build Logs

Example Project (If Possible)

rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Dec 11, 2023
This fixes a regression in .NET 8, where we changed the temporary assembly name when
building using a project file / MSBuild - we started compiling the temporary binding
code in MSBuild instead of in the generator, and in the process we changed the name
of the temporary assembly. This broke logic in bgen that compared the assembly name
to check if a given type is from the temporary assembly or not.

Fix this by checking the actual temporary assembly instead of the name of the assembly
instead.

Fixes xamarin#19612.
@rolfbjarne rolfbjarne added this to the Future milestone Dec 11, 2023
@rolfbjarne rolfbjarne added bug If an issue is a bug or a pull request a bug fix regression The issue or pull request is a regression generator Issues affecting the generator labels Dec 11, 2023
@rolfbjarne
Copy link
Member

I can reproduce, and a fix is in progress.

I'll try to come up with a workaround.

@rolfbjarne
Copy link
Member

Adding this to the binding project seems to fix it:

<Target Name="FixTemporaryAssemblyName" AfterTargets="_ComputeCompileApiDefinitionsInputs">
  <PropertyGroup>
    <_CompiledApiDefinitionAssembly>$(DeviceSpecificIntermediateOutputPath)temp.dll</_CompiledApiDefinitionAssembly>
  </PropertyGroup>
</Target>

@Sleeckx
Copy link
Author

Sleeckx commented Dec 12, 2023

@rolfbjarne It does, thanks for the workaround!

rolfbjarne added a commit that referenced this issue Dec 14, 2023
This fixes a regression in .NET 8, where we changed the temporary assembly name when
building using a project file / MSBuild - we started compiling the temporary binding
code in MSBuild instead of in the generator, and in the process we changed the name
of the temporary assembly. This broke logic in bgen that compared the assembly name
to check if a given type is from the temporary assembly or not.

Fix this by checking the actual temporary assembly instead of the name of the assembly
instead.

Fixes #19612.
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Dec 14, 2023
This fixes a regression in .NET 8, where we changed the temporary assembly name when
building using a project file / MSBuild - we started compiling the temporary binding
code in MSBuild instead of in the generator, and in the process we changed the name
of the temporary assembly. This broke logic in bgen that compared the assembly name
to check if a given type is from the temporary assembly or not.

Fix this by checking the actual temporary assembly instead of the name of the assembly
instead.

Fixes xamarin#19612.

Backport of xamarin#19619.
rolfbjarne added a commit that referenced this issue Dec 15, 2023
This fixes a regression in .NET 8, where we changed the temporary assembly name when
building using a project file / MSBuild - we started compiling the temporary binding
code in MSBuild instead of in the generator, and in the process we changed the name
of the temporary assembly. This broke logic in bgen that compared the assembly name
to check if a given type is from the temporary assembly or not.

Fix this by checking the actual temporary assembly instead of the name of the assembly
instead.

Fixes #19612.

Backport of #19619.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug If an issue is a bug or a pull request a bug fix generator Issues affecting the generator regression The issue or pull request is a regression
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants