ARM64 Support - Not able to Use options related to DbContext

[aathar]

Bug description / exact reproduction steps

I just noticed that I am able to use the following options with the version 2.6.1186
"Reverse Engineer, Visualize Database Schema and ER Diagram"
The tool is now providing the mmd and dgml files and is able to generate the models (Reverse Engineer)

Problem
The options for DbContext "Add DbContext Diagram", "ViewDbContext DDL SQL" are throwing the error that I posted in my previous comment.

Thanks for looking into it, I am sure we are very close to resolving it.

Your code

`System.InvalidOperationException: Error:
System.IO.FileLoadException: Could not load file or assembly 'C:\Projects\Umbraco\mymy.COM (Umbraco)\mymycms\bin\Debug\net9.0\mymycms.dll'. The assembly architecture is not compatible with the current process architecture.
File name: 'C:\Projects\Umbraco\mymy.COM (Umbraco)\mymycms\bin\Debug\net9.0\mymycms.dll'
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
at System.Reflection.Assembly.LoadFile(String path)
at Modelling.EfCoreModelBuilder.Load(String assemblyPath) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 104
at Modelling.EfCoreModelBuilder.GetOperations(String outputPath, String startupOutputPath) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 89
at Modelling.EfCoreModelBuilder.BuildResult(String outputPath, String startupOutputPath, Boolean generateDdl) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 35
at Modelling.EfCoreModelBuilder.GenerateDebugView(String outputPath, String startupOutputPath) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 23
at Modelling.Program.Main(String[] args) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\Program.cs:line 39

at async Task EFCorePowerTools.Handlers.ModelAnalyzerHandler.GenerateAsync(string outputPath, Project project, GenerationType generationType)`

Stack traces

`System.InvalidOperationException: Error:
System.IO.FileLoadException: Could not load file or assembly 'C:\Projects\Umbraco\mymy.COM (Umbraco)\mymycms\bin\Debug\net9.0\mymycms.dll'. The assembly architecture is not compatible with the current process architecture.
File name: 'C:\Projects\Umbraco\mymy.COM (Umbraco)\mymycms\bin\Debug\net9.0\mymycms.dll'
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
at System.Reflection.Assembly.LoadFile(String path)
at Modelling.EfCoreModelBuilder.Load(String assemblyPath) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 104
at Modelling.EfCoreModelBuilder.GetOperations(String outputPath, String startupOutputPath) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 89
at Modelling.EfCoreModelBuilder.BuildResult(String outputPath, String startupOutputPath, Boolean generateDdl) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 35
at Modelling.EfCoreModelBuilder.GenerateDebugView(String outputPath, String startupOutputPath) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\EFCoreModelBuilder.cs:line 23
at Modelling.Program.Main(String[] args) in C:\dev\GitHub\EFCorePowerTools\src\Core\efpt80.core\Program.cs:line 39

at async Task EFCorePowerTools.Handlers.ModelAnalyzerHandler.GenerateAsync(string outputPath, Project project, GenerationType generationType)`

EF Core Power Tools version

2.6.1186

EF Core Power Tools CLI version

No response

Database provider

SQL Server (Express)

Target framework

.NET 9.0

IDE

Visual Studio Insiders 2026

Additional features in use

• T4 templates
• SQL Server .dacpac
• Handlebars template

[BillKrat]

@ErikEJ I'm unable to run EFTP 2.6.1186 on my Mac Mini running Parallels (developing in Windows 11 - arm64). I'm going to take the steps necessary to get a local branch running so that I can address issue #3122, which I'll be working on this weekend. Not being well versed with the multi-version aspects of the code (or how to test), I thought it might be best to only provide a PR for only the code changes related to issue - please advise if you feel we may need to tag-team this since I'm developing/running in the arm64 environment.

I pulled the latest code and ran locally, I got the error attached below:

• TdsParser-Error.txt

I first sent the above TdsParser-Error.txt to Copilot, and upon it's response I asked it to evaulate the screenshot of SqlClient versions (above right); it reported the following:

Yes. Two issues stand out in that versions view that line up with your SNI load failure:

1. Mixed SqlClient versions across projects
   • You have 5.1.6, 6.0.2 and 6.1.1 in the same solution (some transitive, some top-level).
   • The runner that fails in your stack trace is efreveng80 (RevEng/efreveng80), and it pulls Microsoft.Data.SqlClient transitively.
   • Mixing major/minor versions across executables/libraries is a frequent source of native-asset (SNI) copy issues and binding surprises.
2. SqlClient is only transitive in the runner(s)
   • When Microsoft.Data.SqlClient is only a transitive dependency of the executable, the native SNI runtime asset is sometimes not copied to the output folder.
   • That produces exactly the DllNotFoundException you’re seeing (Microsoft.Data.SqlClient.SNI.dll).
   What to do
   • Pin a single Microsoft.Data.SqlClient version across all reverse-engineering executables and libraries (efreveng80, efcpt.8, RevEng.Core.*). Use the same version everywhere (6.1.1 is fine), and avoid having 5.1.6/6.0.2/6.1.1 mixed.
   • Make it a top-level PackageReference in the runner executables (at minimum efreveng80 and efcpt.8) so the native SNI asset is copied to their bin folders.
   • Clean and rebuild; verify the runner’s output contains Microsoft.Data.SqlClient.SNI.x64.dll next to the exe.
   Optional mitigations
   • If you must keep net48 VSIX projects on 5.1.x, keep them isolated from the runners and ensure Visual C++ Redistributable is present.
   • As a fallback, you can force managed networking to avoid the native SNI dependency in the runners by setting: AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseManagedNetworkingOnWindows", true); Do this before the first SqlClient use.
   Bottom line: unify SqlClient to one version and make it a top-level dependency in the runner projects; that usually resolves the SNI DLL load error.

[ErikEJ]

@BillKrat I think you are confusing things. Inability to login is not an ARM related issue.

But your inability to run locally is because the master branch is broken, as it currently contains broken tool zip files.

I will update tomorrow and let you know. When pulling latest master, make sure to delete any reveng* folders in your temp folder.

Hope this makes sense.

[BillKrat]

@ErikEJ Okay, I re-entered my credentials and everything is working as expected (not running locally). I fell into a rabbit hole once I started working locally - it must have corrupted things.