Impossible to add a migration with efcore 10 when targeting net48

[mnivet]

Bug description

Using dotnet ef migrations add command with the --framework net48 option do not work with dotnet-ef version 10.0.2 nor 10.0.3

We have some projects that target both net10.0 and still net48
We were used to use the dotnet ef migrations add command with the --framework net48 option to produce code compatible with net48.

However now we migrate from EFCore8 to EFCore10 (10.0.2) we face an issue where it try to load ef assembly.

If we target net10.0 in the command it works, but the code produced for the ModelSnapshot do not compile on net48.

Your code

dotnet ef migrations add newmigration --context AppDbContext --project .\Repository\EFCore --framework net48

Stack traces

System.BadImageFormatException: Could not load file or assembly exception 'ef, Version=10.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' 
Filename : 'ef, Version=10.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Reflection.Assembly.Load(String assemblyString)
   at System.Runtime.Serialization.FormatterServices.LoadAssemblyFromString(String assemblyName)
   at System.Reflection.MemberInfoSerializationHolder..ctor(SerializationInfo info, StreamingContext context)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.EntityFrameworkCore.Tools.AppDomainOperationExecutor..ctor(String assembly, String startupAssembly, String designAssembly, String project, String projectDir, String dataDirectory, String rootNamespace, String language, Boolean nullable, String[] remainingArguments, IOperationReportHandler reportHandler)
   at Microsoft.EntityFrameworkCore.Tools.Commands.ProjectCommandBase.CreateExecutor(String[] remainingArguments)
   at Microsoft.EntityFrameworkCore.Tools.Commands.MigrationsAddCommand.Execute(String[] args)
   at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
   at Microsoft.EntityFrameworkCore.Tools.Program.Main(String[] args)

Verbose output

EF Core version

10.0.2

Database provider

No response

Target framework

NetFramework

Operating system

Windows 11

IDE

No response

[mnivet]

Important info that I was missing, our projects target EFCore 3.1.32 when compiled against net48, but EFCore 10.0.2 when compiled against net10.
It’s a bit tricky.

[roji]

@mnivet that is... an odd and problematic situation to be in - EF Core 3.1 and 10.0 are very, very different. I understand that you require netfx compat (hence EF 3.1), but the situation is overall not one you want to stay in.

In any case I know @AndriySvyryd did some fixes around this recently, assigning to him to deduplicate.

[AndriySvyryd]

I agree with @roji, ef tools v10.x are not supported with EF Core 7.x or older, you will have to use an older version of the tool for net48

[mnivet]

Ok, not supporting version of EF Core 7.x or older is perfectly understandable, and probably a good thing for global maintainability.
And I have already change our scripts to target an older version of the tool on the fly for our case (thanks to the new capabilities of SDK 10 dotnet tool exec it was easy)

But it would have be great if the tool clearly report the issue (supported version) instead of crashing.
Or at least if that limitation appear somewhere in some documentation. I’ve found nothing about that.
I let you think of that and decide internally what you want to do with that idea.
No need to continue on this closed issue.