In most projects, EF Core is only used with a single database provider. However, I'm currently working on a project, which requires us to transition from one database provider to another. And since we can't simply stop all other development until this process is complete, we need to support two different database providers in parallel, at least temporarily.
In my recent dealings with MySQL, I learned that some connection string options affect the behavior to such an extent that the code will break unless they are set correctly. To prevent the application failing because somebody configured the connection string wrong, you can make sure in code that the selected options are set correctly.
Using Entity Framework Core for loading large amounts of data into database is not very efficient. The bulk operations from the EFCore.BulkExtensions NuGet package can help in such scenarios. Unfortunately, not all of them work (yet) for all database types.
I've been recently involved in migrating a .NET project from Microsoft SQL Server to MySQL. While most of it went pretty smoothly, we did encounter some challenges with GUID/UUID values.
Conventions for relationships between entities in Entity Framework Core do a great job for simple scenarios. Unfortunately, they fail as soon as you want to have more than one relationship between the same two entities. At that point, you have to configure both relationships manually.
The navigation properties in Entity Framework Core models are not only useful for reading hierarchical data from database, but can also very much simplify importing hierarchical data from other sources like JSON files.
Recently, I was tasked with troubleshooting an EF Core migrations issue in a codebase I was not familiar with. The problem was that the Update-Database command didn't detect the migration in the project. It behaved as if the migration file wasn't present at all.
EF Core is pretty strict about nullable reference types. I wrote about this before in the context of migrations, but it also affects loading of data from the database. If you try to load a null value into a non-nullable string property, a SqlNullValueException will be thrown.
Nullable reference types have a greater impact on projects using Entity Framework Core than other projects. Although this is well documented, I have found that many developers are not aware of this.
Mocks can be a helpful tool for replacing external dependencies in unit tests. However, caution is required when you embark on that route or you could end up with tests that don't really test your code under test.
In a recent discussion of pros and cons of using EF Core in-memory database provider for testing, the idea of using SQL Server Express LocalDB instead came up. I remembered reviewing an article about this last year. But after reading it once again, it turned out that some work would still be required to create a working sample.
Tuples, as added to C# 7, can be a nice alternative to anonymous types in LINQ when you only want to return a subset of values from the queried type. Before tuples, this was only possible by creating an anonymous type in the Select method. Now you can create a tuple instead. However, if you try to do that with EF Core, the code won't compile. How come?
There's no built-in solution in EF Core for getting the SQL query that is going to be sent to the database. I could find an implementation by Nick Craver which worked fine with EF Core 2.0.0, but fails with the current version of EF Core (2.1.4). Since I really needed it for the latest version, I decided to put the effort in to make it work.
Interpolated strings in C# 6 introduced a simplified syntax for most use cases of String.Format. The new syntax has several immediate advantages, but its internal implementation also lends itself to some innovative usage. In EF Core 2.0, interpolated strings can be used to write safe SQL queries with shorter syntax. Let's take a look at how this is implemented.