我有一个.net核心解决方案,其中包含一个数据库项目(类库)和一个控制台应用程序。数据库项目包含EF迁移,并且要执行df$job <- as.factor(df$job)
,大多数方法在一个地方或另一个地方使用硬编码的连接字符串。
为避免硬编码(和/或重复),我在解决方案根目录中创建了一个共享的Add-Migration
文件,并在我的appsettings.json
方法和类库中使用了该文件
在控制台应用程序中
Main
并在类库中使用迁移
static void Main(string[] args)
{
var settingPath = Path.GetFullPath(Path.Combine(@"../appsettings.json"));
var builder = new ConfigurationBuilder()
.AddJsonFile(settingPath, false);
var configuration = builder.Build();
var services = new ServiceCollection()
.AddDbContext<MyContext>(options => options.UseSqlServer(configuration["ConnectionStrings:MyDatabase"]))
.BuildServiceProvider();
}
当我使用public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<MyContext>
{
public MyContext CreateDbContext(string[] args)
{
var settingPath = Path.GetFullPath(Path.Combine(@"../appsettings.json"));
var builder = new ConfigurationBuilder()
.AddJsonFile(settingPath, false);
var configuration = builder.Build();
var optionsBuilder = new DbContextOptionsBuilder<MyContext>()
.UseSqlServer(configuration["ConnectionStrings:MyDatabase"]);
return new MyContext(optionsBuilder.Options);
}
}
时,这对于开发很有效,但是在发布控制台应用程序时,它不包含appsettings文件。除了将Powershell脚本作为dotnet run
的一部分运行之外,在项目发布时是否还有其他更干净的方法来包含此文件?
答案 0 :(得分:2)
IDesignTimeDbContextFactory
正是出于其名称所描述的目的。首先,您不应该针对生产数据库运行迁移,如果这样做,则应该为生产生成特定的迁移到您的应用程序(而不是类库)中,并使用您的应用程序进行迁移。请参见docs on using a separate project for migrations。然后,这消除了共享您的appsettings.json的需要。只需将连接字符串保留在您的工厂中即可,因为无论如何它仅用于开发。
现在,您可能在团队环境中遇到了一个问题。但是,即使您使用的是SQLite之类的东西,也可以使用与开发人员无关的相对于项目的路径,并且对于LocalDB,您可以对MSSQLLocalDB实例使用普通的SQL Server连接字符串,这将是相同的对于使用Visual Studio的每个开发人员。无论如何,即使您确实需要由开发人员专门指定连接,在这一点上无论如何都应该使用用户机密,因为您不希望该信息被提交给源代码控制。否则,每个开发人员最终都会破坏对方的appsettings.json副本,并且您将一团糟。
长短不一,只需在工厂中对连接字符串进行硬编码,或者,如果不能,请使用用户密码作为连接字符串。无论哪种情况,都不需要共享appsettings.json。
答案 1 :(得分:0)
我之前做过的方法是在运行dotnet ef
时指定启动项目(使用-s
开关-选项位于https://docs.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet#common-options
)
它很快就会变得混乱,并且可能最容易为该项目编写一些处理此类问题的包装器脚本。