F# Type Providers and Continuous Integration, Part 2

Question

This is a (actually it is several) follow-up question to my previous question on F# Type Providers and Continuous Integration.

It seems to me that it would be a good idea to use the SqlDataConnection type provider as a compile-time check that the code/database integrity remains intact in feature-branch driven development; you would know at every commit/build that no changes have been made to the code that has not also been applied to the database, assuming that building the database is also a part of your CI process.

However, a couple of questions arise:

1. The name (as well as the location) of the config file is not the same at compile time as at runtime, e.g. app.config -> MyApp.exe.config, which will result in a runtime error if you try to use

   SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
   

   (Actually, specifying ConfigFile="app.config" is not necessary, since it is the default value.)

   The runtime error can be avoided by copying the app.config file to the output directory (there’s a setting for that), but that would result in having both an app.config and a MyApp.exe.config file in the output directory. Not very pretty. Adding a separate configuration file for type providers would be another solution, but imho that’s not very pretty either.

   Question: Has anyone come up with a more elegant solution to this problem?

2. The next problem arises when you come to the build server. It is most likely that you don’t want to compile against the same database as you did while developing, thus requiring a different connection string. And yes, in production you’d need yet another one.

   Question: How do you go about solving this in the most convenient way? Remember, the solution has to be a working part of a CI process!

3. This strategy would require generating the database on each build at the build server, probably from a baseline script with some feature/sprint update scripts.

   Question: Has anyone tried this and how did it affect build times? If yes, how did you create this step?

Answer 1

At runtime you can use the GetDataContext overload that accepts a connection string. See here: Providing connection string to Linq-To-Sql data provider