We've run into a bug with EF Core which appears to be in the EF Core team's court, not ASP.NET Zero's. The bug is documented here: https://github.com/aspnet/EntityFrameworkCore/issues/18178 It was supposed to be fixed with the 3.1.0 release which came out today, but we continue to experience the issue after upgrading Nuget packages. So far the only project we're experiencing this with is our ASP.NET Zero based solution at v8.0.0, and as such we need to share the codebase with the EF team.
How can we go about sharing the A0 codebase with the EF Core team without violating your license terms?
8.0.0 appears to contain the .gitignore for the MVC version of the project. Can you provide the proper version?
This is one of the more maddening things about ASP.NET Zero/ABP- when debugging the application locally I want to see where exceptions are coming from at runtime within my IDE. I know they're written to the log but that's not an efficient workflow. How can I keep ANZ/ABP from swallowing exceptions when running locally? Is this primarily a symptom of async code or specific to the platform?
I've noticed that ASP.NET Zero/ABP is still adding EF migrations to the EFCore project as of earlier this year. From time to time we update the core ASP.NET Zero framework by merging the latest code changes into our development branch and reconciling any conflicts. For the most part we try not to touch any code files that are part of the framework, but we do have to add our own migrations from time to time. Eventually we're going to find ourselves in a position where ANZ/ABP has added a migration with a timestamp prior to one of our own custom migrations, and upon merging and running update-database, it's not going to work. Is there a best practice in place for handling this situation?
