This repository was archived by the owner on Aug 27, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 27, 2026. It is now read-only.
Delegate IL size regression in C# 11 #1034
Description
Context: dotnet/roslyn#62832 (comment)
On a recent .NET 7 bump, we found a ~4.5% app size regression related to a new C# 11 delegate feature. I set LangVersion=10 for now to prevent the regression: dotnet/android@938b2cb
Instead of emitting e.g.
static Delegate GetGetActionBarHandler ()
{
if (cb_getActionBar == null)
cb_getActionBar = JNINativeWrapper.CreateDelegate ((_JniMarshal_PP_L) n_GetActionBar);
return cb_getActionBar;
}generator should instead emit:
static Delegate GetGetActionBarHandler ()
{
if (cb_getActionBar == null)
cb_getActionBar = JNINativeWrapper.CreateDelegate (new _JniMarshal_PP_L(n_GetActionBar));
return cb_getActionBar;
}This should avoid a C#11 "caching method group conversion", allowing Mono.Android.dll assembly size to be ~unchanged between C#10 and C#11.
Workaround
To avoid this size regression, set LangVersion to 10 in your Android bindings project:
<LangVersion>10</LangVersion>Android bindings projects do not use any features that require C# 11.
Activity
jonathanpeppers commentedon Aug 1, 2022
See recommendation here: dotnet/roslyn#62832 (comment)
[-]Mono.Android.dll, C# 11, and .NET 7[/-][+]`generator` should use `new DelegateType(method)`, not `(DelegateType) method`[/+][-]`generator` should use `new DelegateType(method)`, not `(DelegateType) method`[/-][+]Delegate IL size regression in C# 11[/+]jonpryor commentedon Sep 1, 2022
I'm not sure how important this is, i.e. "fix now" or "fix for .NET 8"?
We have a workaround for now -- set
$(LangVersion)=10 -- so it doesn't need to be done immediately. We will need to fix this before we can buildMono.Android.dllw/ C# 11.Other binding projects (AndroidX, GooglePlayServices) will also hit this behavior, and when built against
net7.0-android, they will also hit this assembly size regression. However, I don't know how common usingnet7.0-androidas a target framework will be.jonathanpeppers commentedon Sep 1, 2022
I have a feeling we might also want to keep AndroidX/GPS on net6.0-android for a while. Just so we can support both & the .nupkg files won't grow by 50%.
jpobst commentedon Sep 1, 2022
My opinion is that this is too risky a fix to debut in .NET 7 RC2.
We should be good with
Mono.Android.dllwith the workaround. We currently have no plans to addnet7.0-androidto AndroidX/GPS/etc. (It would be the same binary asnet6.0-android.)This leaves user bindings that are updated to
net7.0-android. We estimate they will see a roughly ~4.5% size increase. I think given how small non-Mono.Android.dll bindings tend to be this should be acceptable for .NET 7. The workaround of setting<LangVersion>to10is available if a user wants to recover that size.One possible alternative is we could default Android Bindings projects to
<LangVersion>10</LangVersion>in our.targets? Our generated code does not use any C# 11 specific features.jonpryor commentedon Sep 1, 2022
I agree that this should not debut in .NET 7 RC2. That's too soon.
It could plausibly debut in some "future service release", e.g. .NET 7.0.200 (or .300, or…). This change would not an ABI change, would not change API, and would not require publishing new packages.
For the time being, scheduling as a .NET 8 feature makes the most sense.
[Java.Interop] Avoid some method group conversions
[Java.Interop] Avoid some method group conversions (#1050)
[generator] Avoid C#11 delegate cache overhead. (#1053)
Bump to xamarin/Java.Interop/main@5318261 (#7502)
[generator] Avoid C#11 delegate cache overhead. (#1053)