Can't create migration after updating to Visual Studio 2019

[AlonCG]

So this is a bit embarrassing ... I am not exactly sure when migrations broke, and am not sure how to debug a CLI tool running from my app code. So any advice or direction pointing would be appreciative.

So... the last time we ran a migration was this past April. From what I remember, it worked fine. We upgraded to ASP DotNet Core 2.2 (on top of Full DotNet since we still need TPT inheritance in EF 6.2) around that time. Since then ... we have upgraded our dev stack DotNet Core SDK 2.2.402, DotNet Framework 4.7.2, EF 6.3, and Visual Studio 2019. (We are trying to prep our app for Core 3.0)

This has worked fine for almost two months now, until today, when we needed to create a new migration. When I run the command line that I've been running for sometime:

dotnet ef6 migrations add Irrx-IpAddressList -o Core\Data\Migrations --verbose

I get the following error:

[ProjectReader] AssemblyName: Irrx.Root
[ProjectReader] RootNamespace: Irrx
[ProjectReader] projectName: irrx.root
[ProjectReader] Resolved assembly name: Irrx.Root
[ProjectReader] Resolved project name: Irrx.Root
[ProjectReader] Resolved project root namespace: Irrx
Unhandled Exception: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
   at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
   at System.Reflection.Assembly.GetTypes()
   at Migrator.EF6.Tools.Executor..ctor(Boolean verbose, String connectionString, String providerName, String context)
   at Migrator.EF6.Tools.CommonConfiguration.CreateExecutor()
   at Migrator.EF6.Tools.MigrationsCommand.<>c__DisplayClass1_2.b__6()
   at Microsoft.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
   at Migrator.EF6.Tools.Program.Main(String[] args)

I've tried using different SDKs but all ended with the same error. I've also tried older dotnet frameworks ... net 461 & net471 and EF 6.2 without luck.

Not sure how to debug a CLI tool, but I have cloned the repo. Looking at the source code it would seem from the exception stack that _types = _startupAssembly.GetTypes(); could be failing. Now Irrx is a class library as we had implemented the suggestions here #37 since the beginning.

Just not sure where to go from here.

[mrahhal]

Hi,

Are you able to get the BasicConsoleApp sample in this repo working? Can you run migrations against it?

Personally, I'm using this (latest version) with aspnetcore 2.x and VS 2019, and it's working the just fine.

[AlonCG]

So yeah ...

in short the BasicConsoleApp (and WithIdentity.Models) works fine. Our app exhibits the same error in the OP on three dev machines so something in our codebase ... within the last 7 months ... has broken the ability to run migrations.

Only differences that I know of for sure is that our DBConfig is in a class library and the connection string comes from an appsettings.json file. Maybe the namespace for the DbContext is nested too deep. Trying to figure out what we did since April!

[mrahhal]

So sorry, I wish I can help :/ Some of these problems have been persistent and impossible to resolve completely, wish I could resolve those edge cases. Please update me whenever you can, and I'll see if I can find something.

[AlonCG]

For sure ... realize it is not an issue with the Migrator ... just frustrating that something that has worked for 2.5yrs ... breaks! But guess that is why we are in this business to begin with. All the best, will update you on the resolution.

[AlonCG]

Update: I restructured the Irrx.Root class library and replaced some dependencies that were not really needed. Though this had been working since 02 January 2018 and suddenly stopped, I am glad to report that it is working again.

FWIW ... I no longer needed to have a any binding redirects (even though I am using the latest Json.Net) so I didn't need to copy a config file (re. #37). I also switched to the dynamic connection string loading that was mentioned way back in #3. I had my own dynamic solution already running, but it was overkill and this approach required less dependencies.

[mrahhal]

Great to know! Could have been caused by any kind of update of any transitive dependency you had. It's pretty chaotic. Good that it's working again.