这是关于F#Type Providers和Continuous Integration的上一个问题的一个(实际上是几个)后续问题.
在我看来,使用SqlDataConnection类型提供程序作为编译时检查是一个好主意,在特征分支驱动的开发中代码/数据库完整性保持不变; 假设构建数据库也是CI过程的一部分,那么在每次提交/构建时都会知道没有对尚未应用于数据库的代码进行任何更改.
但是,出现了几个问题:
配置文件的名称(以及位置)在编译时与运行时不同,例如app.config - > MyApp.exe.config,如果您尝试使用,将导致运行时错误
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
Run Code Online (Sandbox Code Playgroud)
(实际上,ConfigFile="app.config"没有必要指定,因为它是默认值.)
通过将app.config文件复制到输出目录(有一个设置)可以避免运行时错误,但这会导致在输出目录中同时包含app.config和MyApp.exe.config文件.不是很漂亮 为类型提供程序添加单独的配置文件将是另一种解决方案,但imho也不是很漂亮.
问题:有没有人想出更优雅的解决方案来解决这个问题?
当你来到构建服务器时,会出现下一个问题.您很可能不希望在开发时对同一数据库进行编译,因此需要不同的连接字符串.是的,在制作中你还需要另一个.
问题:你如何以最方便的方式解决这个问题?请记住,解决方案必须是CI流程的工作部分!
此策略需要在构建服务器上的每个构建上生成数据库,可能来自具有某些功能/ sprint更新脚本的基线脚本.
问题:有没有人试过这个,它是如何影响构建时间的?如果是,您是如何创建此步骤的?
我们有一个Visual Studio 2010解决方案,其中包含几个符合Jeffery Palermo的Onion Architecture模式的C#项目(http://jeffreypalermo.com/blog/the-onion-architecture-part-1/).我们有一个UI项目,它是一个ASP.Net MVC项目,我们有一个名为Infrastructure的C#类库项目,由UI项目引用.在我们的基础结构项目中,我们添加了一个app.config文件,以包含特定于Infrastructure项目的设置.在运行时,app.config文件似乎不可用于Infrastructure项目,只有UI项目中包含的web.config文件.我们不希望将与Infrastructure项目相关的设置放入UI项目中的web.config文件中,UI不需要这些设置.我们如何在运行时使Infrastructure的app.config文件可用?我们想也许我们应该在构建应用程序时将一个Post Build Copy复制到UI目录中 - 这是正确的方法,