"dotnet ef migrations add" replaces \r\n with \n when calling on mac/linux

Question

I've got a repeatable issue with creating new migrations with dotnet ef cli tool. I work on a project with developers mainly using windows and I with no major problems work on MacOS and Linux. We have fluent entity configuration with some data seeding using .HasData() method

 builder.HasData(new SomeType
        {
            NameEn = @"multi
                        line string"
        });

when migration is then created on Windows it produces migration files with "\r\n" for every encounter of new line, but then when any migration is created on mac/linux system it catches it as a change and produces migrationBuilder.UpdateData entries with "\r\n" being replaced with just "\n". And on the windows with next migration it is again caught and converted back to "\r\n".

It makes no difference for successful applying of the migration to the DB, but it successfully obfuscates the git diff result and makes it harder to review. Unnecessary updates I don't need to mention...

Does anybody encountered such an issue? Any solutions to it? I could not find any reported issue on this and it seems to me that it's not so rare that people on the team work on different systems.

I use "Entity Framework Core .NET Command-line Tools 6.0.0"

Thanks in advance for any help

Answer 1

Ran in to this recently as well, not sure why it's not a breaking change listed in the documentation. To the best we can tell, EF Core is now adding the line endings to multi-line strings in seed data based on the native file system at the time of the migration. As you've found, this creates the ping pong situation with multi-environment teams since git normalizes the line endings in your working directory.

When upgrading to EF Core 6, you'll most likely get a lot of changes to the snapshot on your first migration no matter what, as the migration will include the strings with their line endings. But you can avoid the continued back and forth, as well as the actual UpdateData call within a migration, with:

• A .gitattributes file to force the file your seed data strings are in to respect a CRLF, or LF setting, no matter the environment. Read more here.

  • You can use git ls-files --eol left column results to determine the line endings of your files as they're already checked in, so you know which to pick to make it the easiest.

• If you're bringing in data from a file, or otherwise reading it somehow, manually put specific line endings in the string as part of that read. You can also use the .gitattributes method here on the data files so the line endings are consistent.