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

Internals part #1: platform backends #10336

Merged
merged 6 commits into from
Feb 14, 2023
Merged

Internals part #1: platform backends #10336

merged 6 commits into from
Feb 14, 2023

Conversation

maxkatz6
Copy link
Member

@maxkatz6 maxkatz6 commented Feb 14, 2023

What does the pull request do?

Hides (almost) all of interface implementations and public API types that should be internal in these assemblies:

  • Avalonia.Android
  • Avalonia.Browser
  • Avalonia.iOS
  • Avalonia.Native
  • Avalonia.X11
  • Avalonia.FreeDesktop (ended up with no public members at all, as it is directly used from the Avalonia.X11)
  • Avalonia.Win32
  • Avalonia.Skia
  • Avalonia.Direct2D

Note, win32 automation COM interfaces weren't made internal, as whole automation stops working because of that. I couldn't figure it out quickly, so moved it out of this PR.

Also, it seems to not be possible to disabled resources generation from _UpdateAndroidResgen, so these 1800 lines of public API are still there.

It should be easier to review changes with this commit from API-listing generator branch: aeea42f

Part of #6666

@maxkatz6 maxkatz6 changed the title Internals pass 1 Internals part #1: platform backends Feb 14, 2023
@avaloniaui-team
Copy link
Contributor

You can test this PR using the following package version. 11.0.999-cibuild0029978-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

@maxkatz6 maxkatz6 merged commit 7fdd1eb into master Feb 14, 2023
@maxkatz6 maxkatz6 deleted the internals-pass-1 branch February 14, 2023 11:35
@grokys
Copy link
Member

grokys commented Feb 14, 2023

Note, win32 automation COM interfaces weren't made internal, as whole automation stops working because of that.

Yeah I ran into this: it seems that COM interfaces need to be public to work with the inbuilt COM interop? A pretty strange requirement, and one that I've not actually seen documented anywhere. @jkoritzinsky maybe you might have some insight here?

In the longer-term we need to move away from .NET's inbuilt COM support but that's not possible yet.

@jkoritzinsky
Copy link
Collaborator

It looks like the interfaces are marked [ComVisible(true)]. The ComVisible attribute depends on visibility. Since you're consuming these interfaces instead of authoring them (aka Windows defines them, not you), you should mark them with [ComImport] instead of [ComVisible(true)]. Then it should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants