在 mac/linux 上调用时，“dotnet ef migrations add”将 \r\n 替换为 \n

Question

我在使用 dotnet ef cli 工具创建新迁移时遇到了可重复的问题。我与主要使用 Windows 的开发人员合作开展一个项目，在 MacOS 和 Linux 上工作没有出现重大问题。我们使用 .HasData() 方法进行了流畅的实体配置和一些数据播种

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

当在 Windows 上创建迁移时，它会为每次遇到新行生成带有“\r\n”的迁移文件，但是当在 mac/linux 系统上创建任何迁移时，它会将其捕获为更改并生成 migrationBuilder.UpdateData 条目“\r\n”被替换为“\n”。在 Windows 上进行下一次迁移时，它会再次被捕获并转换回“\r\n”。

这对于成功地将迁移应用到数据库没有什么影响，但它成功地混淆了 git diff 结果并使其更难以审查。不必要的更新我不需要提及......

有人遇到过这样的问题吗？有什么解决办法吗？我找不到任何有关此问题的报告问题，在我看来，团队中的人员在不同的系统上工作的情况并不少见。

我使用“Entity Framework Core .NET 命令行工具 6.0.0”

预先感谢您的任何帮助

Answer 1

最近也遇到了这个问题，不知道为什么它不是文档中列出的重大更改。据我们所知，EF Core 现在正在根据迁移时的本机文件系统将行结尾添加到种子数据中的多行字符串中。正如您所发现的，这会在多环境团队中造成乒乓球情况，因为 git 会规范化工作目录中的行结尾。

升级到 EF Core 6 时，无论如何，您很可能会在第一次迁移时对快照进行大量更改，因为迁移将包含带有行结尾的字符串。但是您可以通过以下方式避免持续的来回以及迁移中的实际 UpdateData 调用：

• .gitattributes 文件，用于强制种子数据字符串所在的文件遵循 CRLF 或 LF 设置，无论环境如何。在这里阅读更多内容。

  • 您可以使用git ls-files --eol左列结果来确定文件的行结尾，因为它们已经签入，因此您知道选择哪个以使其最简单。

• 如果您从文件中引入数据，或者以其他方式读取数据，请手动将特定行结尾放入字符串中作为读取的一部分。您还可以在数据文件上使用 .gitattributes 方法，以便行结尾保持一致。