Remove InternalsVisibleTo attributes for .NET MAUI Community Toolkit

[jfversluis]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description of Change

Removes all InternalsVisibleTo attributes that grant the .NET MAUI Community Toolkit access to internal APIs. This is the same change as #33442 (which was reverted in #34047 for .NET 10 SR4), now targeting net11.0 to give the toolkit team time to migrate.

Previous attempts:

• Remove InternalsVisibleTo for Toolkit #28994 — First removal (reverted in Revert "Remove InternalsVisibleTo for Toolkit" #29321 because toolkit wasn't updated)
• Make internal types used by MAUI Toolkit public #29443 — Made some types public (ITextElement, ICornerElement, etc.)
• Remove InternalsVisibleTo attributes for .NET MAUI Community Toolkit #33442 — Second removal in SR4 (reverted in Revert "Remove InternalsVisibleTo attributes for .NET MAUI Community … #34047 because toolkit still wasn't updated)

Files Modified

File	Entries Removed
src/Controls/src/Core/Properties/AssemblyInfo.cs	6
src/Controls/src/Xaml/Properties/AssemblyInfo.cs	6
src/Essentials/src/AssemblyInfo/AssemblyInfo.shared.cs	5
src/Core/src/Properties/AssemblyInfo.cs	5

Total: 22 InternalsVisibleTo declarations removed for CommunityToolkit.Maui, .Core, .Embedding, .UnitTests, .Markup, .Markup.UnitTests.

CommunityToolkit.Maui.Embedding has never been published to NuGet, so that grant was already dead.

Impact on CommunityToolkit.Maui 15.0.0 (verified — see verification comment below)

The toolkit has made great progress: everything the older tables in this PR used to describe (AvatarView/FontElement/TextElement/ImageElement, GravatarImageSource/ImageSource.CancellationTokenSource, AppThemeResourceExtension/IResourcesProvider, StreamWrapper, RequireFontManager, InvalidateMeasureInternal, …) is already resolved in 15.0.0. Mac Catalyst builds completely clean.

What remains is Android-only. Building pristine CommunityToolkit.Maui 15.0.0 sources against this PR's packages produces 5 errors:

#	MAUI internal API	Toolkit call site	Error
1	Microsoft.Maui.ApplicationModel.IntermediateActivity (internal type, Essentials)	FileSaverImplementation.android.cs:40, FolderPickerImplementation.android.cs:37	CS0122 ×2
2	Microsoft.Maui.Platform.ElementExtensions.ToPlatform(this IElement) — the 1-arg internal overload	Snackbar.android.cs:43	CS1929
3	Microsoft.Maui.JavaObjectExtensions.IsDisposed (internal static class)	Snackbar.android.cs:91	CS1061
4	Microsoft.Maui.JavaObjectExtensions.IsAlive (internal static class)	TouchBehavior.android.cs:109	CS1061
5	Microsoft.Maui.Platform.ViewExtensions.GetParentOfType<T> (internal method)	TouchBehavior.android.cs:44	CS1061

Plus one binary-only break that the compiler hides:

#	MAUI internal API	Toolkit call site	Notes
6	Microsoft.Maui.Controls.DispatcherExtensions.DispatchIfRequiredAsync	UserStoppedTypingBehavior.shared.cs:108,113	The toolkit has its own 3-arg DispatchIfRequiredAsync(IDispatcher, Action, CancellationToken = default). With IVT the 2-arg call sites bind to MAUI's internal one; without IVT a source rebuild silently rebinds to the toolkit's own. Prebuilt 15.0.0 assemblies therefore carry an IL memberref to MAUI's internal method and would throw MethodAccessException. A toolkit rebuild fixes it.

Suggested resolution — items 2–5 are all trivially re-implementable inside the toolkit (a handful of lines each), and item 1 can be replaced with the toolkit's own activity-result plumbing over Platform.CurrentActivity. None of these require MAUI to make anything public.

Consumer note: CommunityToolkit.Maui.Markup must be ≥ 8.0.0

CommunityToolkit.Maui.Markup 7.0.1 contains 45 IL references to MAUI internals (FontElement, TextElement, ImageElement, PaddingElement, PlaceholderElement, SetterSpecificity, BindingExpression, TypedBindingBase..ctor, BindableObject.SetValueCore, BindingBase.Apply/Unapply/GetSourceValue, …) and hard-crashes without IVT. 8.0.0 already has zero — it's clean. Anyone still on 7.0.1 must upgrade.

Issues Fixed

Context: #29444, #34048

cc @TheCodeTraveler

[Copilot]

Pull request overview

This PR removes all InternalsVisibleTo attributes that grant the .NET MAUI Community Toolkit access to internal APIs. This is the third attempt to make this change, now targeting the net11.0 branch to provide the toolkit team sufficient time to migrate away from internal API dependencies.

Changes:

• Removed 22 InternalsVisibleTo declarations across 4 AssemblyInfo files for CommunityToolkit assemblies
• Removed duplicate Controls.TestCases.HostApp entry from Controls/Core AssemblyInfo
• Preserved all other InternalsVisibleTo entries for MAUI's own test and compatibility assemblies

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/Essentials/src/AssemblyInfo/AssemblyInfo.shared.cs	Removed 5 CommunityToolkit InternalsVisibleTo entries
src/Core/src/Properties/AssemblyInfo.cs	Removed 5 CommunityToolkit InternalsVisibleTo entries
src/Controls/src/Xaml/Properties/AssemblyInfo.cs	Removed 6 CommunityToolkit InternalsVisibleTo entries
src/Controls/src/Core/Properties/AssemblyInfo.cs	Removed 6 CommunityToolkit entries + 1 duplicate Controls.TestCases.HostApp entry

[jfversluis]

Moving this to draft, the Toolkit team can get the resulting artifacts from this for testing to make sure that all APIs are replaced.

[kubaflo]

/review -b feature/refactor-copilot-yml

[MauiBot]

⚠️ Merge Conflict Detected — This PR has merge conflicts with its target branch. Please rebase onto the target branch and resolve the conflicts.

[kubaflo]

AI code review for net11.0 target

Verdict: Needs discussion (draft; intentional decoupling with cross-repo coordination cost and red CI)

Independent review (diff-first, then reconciled with the PR narrative). This is not an approval — a human still needs to sign off. PR is a draft.

What the PR does

Removes the [assembly: InternalsVisibleTo("CommunityToolkit.Maui*")] entries from Core, Controls.Core, Controls.Xaml, and Essentials AssemblyInfo files — i.e., the .NET MAUI Community Toolkit will no longer be able to reach MAUI internal members.

Findings

• This is a deliberate API-coupling cleanup, but it is a breaking change for CommunityToolkit.Maui. It only works if CTK no longer depends on any of these internals. That coordination must land on the CTK side first (or simultaneously); otherwise CTK builds break against net11 MAUI. The PR description should link the corresponding CTK change/issue and the migration plan (which internals CTK used and their public replacements).
• The change is purely subtractive and low-risk in this repo — no product code is touched, only friend-assembly grants. Mechanically correct (each block removed cleanly; unrelated InternalsVisibleTo entries preserved). The duplicate InternalsVisibleTo("Controls.TestCases.HostApp") removed from Controls.Core is a no-op since the canonical entry remains above. ✔️
• Confirm no MAUI test/sample assembly transitively relied on these grants via CTK references.

CI

maui-pr and Build Analysis are red, including Build macOS (Release), Run Integration Tests Build (macOS/windows), RunOnAndroid, and a Helix unit-test leg. These failures are consistent with downstream consumers (samples/tests that reference CommunityToolkit.Maui) failing to compile once the internals are withdrawn — i.e., likely PR-caused and exactly what this change is meant to surface. Needs investigation before this can leave draft.

Confidence: medium. The mechanical change is sound; the open questions are the CTK-side coordination and confirming the red CI is the expected downstream fallout rather than an unrelated break.

[kubaflo]

Verdict: NEEDS_DISCUSSION (draft; intentional, purely-subtractive change with a cross-repo coordination cost — not an approval)

All four review models agree this change is mechanically correct and low-risk within this repo: it only removes the CommunityToolkit.Maui* friend-assembly grants from the Core, Controls.Core, Controls.Xaml, and Essentials AssemblyInfo files — no product code is touched (verified: zero CommunityToolkit InternalsVisibleTo entries remain, and the duplicate Controls.TestCases.HostApp removal is a no-op since the canonical entry survives). Because there is no anchorable code defect, there are no inline findings; the only open question is one of coordination/timing for an intentional breaking change to the Toolkit. For the author (while this stays a draft): can you confirm the CTK-side migration off these internals has landed or will land in lockstep — ideally linking the corresponding toolkit change/issue and migration plan — and confirm the red CI is exactly this expected downstream fallout rather than an unrelated break?

CI: maui-pr and Build Analysis are red. The failing legs — Build macOS (Release), Run Integration Tests Build (macOS/windows), RunOnAndroid (macOS), and Helix Unit Tests Windows (Release) — are consistent with MAUI's own templates/tests/samples (which reference CommunityToolkit.Maui, still dependent on these internals) failing to compile once the grants are withdrawn; the remaining legs (Windows builds, Blazor, Samples, iOS runs, MultiProject, Unit Tests) pass. This needs confirmation before the PR leaves draft.

Multi-model review (gpt-5.5 · opus-4.8 · opus-4.6 · gemini-3.1-pro). Comments only — not a formal approval.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34070

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34070"