Question

这是对F# Type Providers and Continuous Integration上一个问题的一个（实际上是几个）后续问题。

在我看来，使用SqlDataConnection类型提供程序作为编译时检查，在功能分支驱动的开发中代码/数据库完整性保持不变是个好主意。你会知道在每次提交/构建时都没有对尚未应用于数据库的代码进行任何更改，假设构建数据库也是CI过程的一部分。

然而，出现了几个问题：

配置文件的名称（以及位置）在编译时与运行时不同，例如app.config - ＆gt; MyApp.exe.config，如果您尝试使用
，将导致运行时错误
```
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
```
（实际上，不需要指定ConfigFile="app.config"，因为它是默认值。）

通过将app.config文件复制到输出目录（有一个设置）可以避免运行时错误，但这会导致在输出中同时包含app.config和MyApp.exe.config文件目录。不是很漂亮为类型提供者添加一个单独的配置文件将是另一种解决方案，但imho也不是很漂亮。

问题：有没有人想出更优雅的解决方案？
当你来到构建服务器时，会出现下一个问题。您很可能不希望在开发时对同一数据库进行编译，因此需要不同的连接字符串。是的，在制作中你还需要另一个。

问题：您如何以最便捷的方式解决这个问题？请记住，解决方案必须是CI流程的工作部分！
此策略需要在构建服务器上的每个构建版本上生成数据库，可能来自带有一些功能/ sprint更新脚本的基线脚本。

问题：是否有人尝试过此操作，它是如何影响构建时间的？如果是，您是如何创建此步骤的？

Answer 1

在运行时，您可以使用接受连接字符串的GetDataContext重载。见这里：Providing connection string to Linq-To-Sql data provider

Answer 2

我熟悉@Gustavo提出的解决方案，但我一直觉得有一些可疑的东西。关于必须两次指定连接字符串的事情......然而，当我再次得到相同的答复时，我慢慢开始意识到答案必须是正确的，并且我认为这是错误的。这些是我的结论：回复声明您可以使用接受连接字符串的GetDataContext重载。如果你把它改成应该，事情会变得更加清晰，至少对我而言。

问题在于我一直认为类定义既是编译时指令又是运行时变量，但即使这是可能的，也不是一个好主意。 ConfigFile参数的默认值是我们已经看到的“app.config”，但该文件在运行时不存在（具有该名称），因此尝试使用它没有意义，因此将GetDataContext作为唯一合理的选择。我建议你这样做：

将编译时设置保存在名为compilation.config的文件中（或您喜欢的任何内容），并在类定义中指定此文件以供使用。
使用GetDataContext重载接受连接字符串进行运行时解析，并在app.config文件中指定此连接字符串。

你最终会得到这样的东西：

type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)

哎呀，这甚至支持SRP;一个文件中的编译时设置和另一个文件中的运行时设置！

关于我的其他问题，我假设答案在于Continuous Deployment管道中的一些脚本。仍然对其他解决方案感兴趣。

F＃类型提供者和持续集成，第2部分

2 个答案: