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

[API Proposal]: Move APIs for generated marshalling to different namespace - System.Runtime.Marshalling #68248

Closed
elinor-fung opened this issue Apr 20, 2022 · 4 comments · Fixed by #68842
Labels
api-approved API was approved in API review, it can be implemented area-System.Runtime.InteropServices blocking Marks issues that we want to fast track in order to unblock other important work
Milestone

Comments

@elinor-fung
Copy link
Member

Background and motivation

For .NET 7, we added various APIs used for p/invoke source generation:

These were all added to the System.Runtime.InteropServices namespace. We are proposing moving them to a separate namespace for clearer separation and discovery.

API Proposal

-namespace System.Runtime.InteropServices
+namespace System.Runtime.Marshalling
{
    public sealed class LibraryImportAttribute : Attribute { ... }
    public enum StringMarshalling { ... }

    public sealed class NativeMarshallingAttribute : Attribute { ... ]
    public sealed class MarshalUsingAttribute : Attribute { ... }
    public sealed class CustomTypeMarshallerAttribute : Attribute { ... }

    public enum CustomTypeMarshallerDirection { ... }
    public enum CustomTypeMarshallerFeatures { ... ]
    public enum CustomTypeMarshallerKind { ... }

    public unsafe ref struct AnsiStringMarshaller { ... }
    public unsafe ref struct ArrayMarshaller { ... }
    public unsafe ref struct PointerArrayMarshaller { ... }
    public unsafe ref struct Utf16StringMarshaller { ... }
    public unsafe ref struct Utf8StringMarshaller { ... }
}

API Usage

using System.Runtime.Marshalling;

[LibraryImport("NativeLib", StringMarshallingCustomType = typeof(AnsiStringMarshaller))]
internal static partial string Method(string s1, string s2);

Alternative Designs

  • Leave LibraryImportAttribute (the triggering attribute for p/invoke source generation) in System.Runtime.InteropServices and only move the new APIs (custom type marshalling attributes, marshaller implementations) that are directly related to marshalling
  • Use a sub-namespace under System.Runtime.InteropServices - for example, System.Runtime.InteropServices.Marshalling

Risks

This would be a breaking change between Preview 4 and 5. The new APIs were just exposed in Preview 4 and the source generator itself will not be included for public use until Preview 5. so we do not expect this to be very impactful.

@elinor-fung elinor-fung added api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Runtime.InteropServices labels Apr 20, 2022
@elinor-fung elinor-fung added this to the 7.0.0 milestone Apr 20, 2022
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Apr 20, 2022
@ghost
Copy link

ghost commented Apr 20, 2022

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

Background and motivation

For .NET 7, we added various APIs used for p/invoke source generation:

These were all added to the System.Runtime.InteropServices namespace. We are proposing moving them to a separate namespace for clearer separation and discovery.

API Proposal

-namespace System.Runtime.InteropServices
+namespace System.Runtime.Marshalling
{
    public sealed class LibraryImportAttribute : Attribute { ... }
    public enum StringMarshalling { ... }

    public sealed class NativeMarshallingAttribute : Attribute { ... ]
    public sealed class MarshalUsingAttribute : Attribute { ... }
    public sealed class CustomTypeMarshallerAttribute : Attribute { ... }

    public enum CustomTypeMarshallerDirection { ... }
    public enum CustomTypeMarshallerFeatures { ... ]
    public enum CustomTypeMarshallerKind { ... }

    public unsafe ref struct AnsiStringMarshaller { ... }
    public unsafe ref struct ArrayMarshaller { ... }
    public unsafe ref struct PointerArrayMarshaller { ... }
    public unsafe ref struct Utf16StringMarshaller { ... }
    public unsafe ref struct Utf8StringMarshaller { ... }
}

API Usage

using System.Runtime.Marshalling;

[LibraryImport("NativeLib", StringMarshallingCustomType = typeof(AnsiStringMarshaller))]
internal static partial string Method(string s1, string s2);

Alternative Designs

  • Leave LibraryImportAttribute (the triggering attribute for p/invoke source generation) in System.Runtime.InteropServices and only move the new APIs (custom type marshalling attributes, marshaller implementations) that are directly related to marshalling
  • Use a sub-namespace under System.Runtime.InteropServices - for example, System.Runtime.InteropServices.Marshalling

Risks

This would be a breaking change between Preview 4 and 5. The new APIs were just exposed in Preview 4 and the source generator itself will not be included for public use until Preview 5. so we do not expect this to be very impactful.

Author: elinor-fung
Assignees: -
Labels:

api-suggestion, area-System.Runtime.InteropServices

Milestone: 7.0.0

@AaronRobinsonMSFT AaronRobinsonMSFT removed api-suggestion Early API idea and discussion, it is NOT ready for implementation untriaged New issue has not been triaged by the area owner labels Apr 20, 2022
@elinor-fung
Copy link
Member Author

elinor-fung commented Apr 20, 2022

@AaronRobinsonMSFT @jkoritzinsky I know when we talked before, I was into moving everything - including LibraryImportAttribute, but I'm actually not sure now. As the triggering attribute, it is not directly for marshalling, so I'm not sure it really fits with the rest. Thoughts?

@AaronRobinsonMSFT AaronRobinsonMSFT added blocking Marks issues that we want to fast track in order to unblock other important work api-ready-for-review API is ready for review, it is NOT ready for implementation labels Apr 20, 2022
@AaronRobinsonMSFT
Copy link
Member

@elinor-fung Agreed on all accounts. I voiced a similar concern to @jkoritzinsky previously. I think we should have a conversation with the API review team and see what some of the API experts think of the concerns.

@terrajobst
Copy link
Member

terrajobst commented May 3, 2022

Video

  • We'd prefer putting these under InteropServices
namespace System.Runtime.InteropServices
{
    public sealed class LibraryImportAttribute : Attribute { /*...*/ }
    public enum StringMarshalling { /*...*/ }
}

// Was previously also approved for System.Runtime.InteropServices

namespace System.Runtime.InteropServices.Marshalling
{
    public sealed class NativeMarshallingAttribute : Attribute { /*...*/ }
    public sealed class MarshalUsingAttribute : Attribute { /*...*/ }
    public sealed class CustomTypeMarshallerAttribute : Attribute { /*...*/ }

    public enum CustomTypeMarshallerDirection { /*...*/ }
    public enum CustomTypeMarshallerFeatures { /*...*/ }
    public enum CustomTypeMarshallerKind { /*...*/ }

    public unsafe ref struct AnsiStringMarshaller { /*...*/ }
    public unsafe ref struct ArrayMarshaller { /*...*/ }
    public unsafe ref struct PointerArrayMarshaller { /*...*/ }
    public unsafe ref struct Utf16StringMarshaller { /*...*/ }
    public unsafe ref struct Utf8StringMarshaller { /*...*/ }
}

@terrajobst terrajobst added api-approved API was approved in API review, it can be implemented and removed api-ready-for-review API is ready for review, it is NOT ready for implementation labels May 3, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label May 3, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label May 5, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jun 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-approved API was approved in API review, it can be implemented area-System.Runtime.InteropServices blocking Marks issues that we want to fast track in order to unblock other important work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants