-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Consider setting NullabilityInfoContextSupport=true in EF's NuGet package #27474
Comments
@eerhardt thanks for this... Can you provide a bit more context on this? Is this simply a property we'd add to our csproj to get rid of the problem? Does it have any downsides/potential issues? Any reason why this standard .NET feature isn't just available by default and needs this opt-in? |
Sure. Check out dotnet/runtime#55860 and dotnet/runtime#56475. Some app models (like Blazor WASM and Maui) want to produce as small of applications as possible. One of the ways to make it smaller is to trim out unnecessary attributes, like the Nulalble attributes: By default, Maui iOS and Android applications have this setting To workaround this, the developer can explicitly set My proposal here is that just by referencing the EntityFramework NuGet packages, we should consider setting
It is a property that would need to be set in a .props/.targets file in your NuGet package. This would then set the property in consumer's projects.
The only downside I can see is that when you aren't in a Maui or Blazor WASM app, and reference the EF package, you would get an extra property that is explicitly setting the value to
It is available by default in a lot of app models. It is just turned off in app models that are concerned with app size. |
Thanks for the info @eerhardt, makes sense. However, if the intent here is to allow WASM/MAUI apps to reduce size, wouldn't it be better to allow EF Core to function properly when NullabilityInfoContextSupport is set to false? In other words, instead of forcing NullabilityInfoContextSupport=true on user applications (and thereby increasing their size), wouldn't it be better for EF Core to not invoke NullabilityInfoContext in the first place (since it doesn't have to in order to work)? I guess we could do a manual check at runtime to see whether the nullability attributes exist or have been trimmed, and based on that avoid calling into NullabilityInfoContext. However, would it be better to expose a static (cached) bool check on NullabilityInfoContext itself, which libraries such as EF Core could use to know whether NullabilityInfoContext is usable? |
Model building needs the attributes, right? |
@ajcvickers oh sure - I was thinking about when the user hasn't enabled NRTs in their project. But thinking about it again, I think you're right: in order to support scenarios where the user does want NRTs, the attributes would have to be conserved, and so we're have to have NullabilityInfoContextSupport=true in any case. I'll do that. |
I'm not 100% sure. The bigger issue that I ran into was fixed with #27099. I think changes like that would be much more impactful to backport to 6.0 if we were open to fixing the Maui experience. The reason being that #27099 is much harder to diagnose and workaround for the developer. This issue gives the developer a good error message and tells them exactly what to do to fix it:
Without #27099 you get an error |
Thanks! The customer I was working with was using SQLite. I just used |
Note from triage: consider patching because it is low risk and will improve MAUI experience. |
To make NRT-based model building work correctly in aggressively trimmed applications (e.g. MAUI). Fixes dotnet#27474
To make NRT-based model building work correctly in aggressively trimmed applications (e.g. MAUI). Fixes dotnet#27474
To make NRT-based model building work correctly in aggressively trimmed applications (e.g. MAUI). Fixes dotnet#27474
To make NRT-based model building work correctly in aggressively trimmed applications (e.g. MAUI). Fixes dotnet#27474
To make NRT-based model building work correctly in aggressively trimmed applications (e.g. MAUI). Fixes dotnet#27474
To make NRT-based model building work correctly in aggressively trimmed applications (e.g. MAUI). Fixes dotnet#27474
i've been facing the same issue on IOS, butwindows and Android it's ok |
@RobertoGFilho which error message are you seeing exactly on iOS? If it's |
hi @roji this error shows up when i try to run Database.Migrate(); or Database.EnsureCreated(); but just iOS. on Aondroid and Windows it's ok. Yes I added NullabilityInfoContextSupport on project file, see: Error message: NullabilityInfoContext is not supported in the current application because 'System.Reflection.NullabilityInfoContext.IsSupported' is set to false. |
@eerhardt any ideas on the above? |
On Xamarin works OK, but MAUI not. |
i will try to create a demo to reproduce this erro.. and i will share here |
@RobertoGFilho please open a new issue with your repro so we can track that separately. |
@RobertoGFilho - if you have an isolated app that reproduces the error, I can take a look. Please ping me on the new issue. |
Hi @eerhardt ! please you can reproduce this erro on this demo : https://github.com/RobertoGFilho/EFCore
I'm using these packages: |
I have openned a new issue #28773 |
When using EF in a .NET Maui Android/iOS application, developers will get a runtime error because .NET MAUI sets
NullabilityInfoContextSupport=false
here:https://github.com/xamarin/xamarin-android/blob/c80dfff7a3183e21d356d2c5835aa0821fd9bd90/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultProperties.targets#L95
and
https://github.com/xamarin/xamarin-macios/blob/e25163f573d31b28fa60f000ce084b8cdb0ca697/dotnet/targets/Xamarin.Shared.Sdk.targets#L136
Since this setting is set to
false
, when EF tries to create aNullabilityInfo
object, an exception is thrown here:efcore/src/EFCore/Metadata/Conventions/NonNullableConventionBase.cs
Lines 54 to 55 in 0e1e95b
We should consider defaulting
NullabilityInfoContextSupport=true
in EF's NuGet package, so when a .NET Maui app starts using EF, they automatically get this support turned on and their app works out of the box.Repro steps
dotnet new maui
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="7.0.0-preview.1.22076.6" />
MainPage.xaml.cs
to:dotnet build -f net6.0-android -r android-arm64 -t:Run
The app will crash with the above exception when it is loaded.
The text was updated successfully, but these errors were encountered: