F# Type Providers and Continuous Integration

Question

The type definition of an F# type provider often requires a constant expression, e.g. for the SQL type provider:

type dbSchema = SqlDataConnection<"Data Source=MySqlServer;Initial Catalog=MyDatabase;">

However, when committing the code to SCM, and further having a build server doing its thing, you probably don’t want to use the same connection string, but rather the connection string of a SQL server database that is generated from the build process.

Is there a solution for this problem?

It would be really nice to be able to make this work, as it would provide a compile-time check of the database access code.

Update The solution proposed by @tomaspetricek worked very well, but I had to add a provider name to the connection string:

<add name="DbConnectionString" providerName="System.Data.SqlClient" connectionString="Data Source=MySqlServer;Initial Catalog=MyDatabase;"/>

Volta

It would be even better if that string was sourced from a configuration file. – Lemnos

@RobertHarvey Indeed, that's exactly what can easily be done ;-) – Baseboard

Answer 1

You can certainly specify the connection string using a key in a configuration file (see MSDN documentation):

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

In general, a type provider may require some constant expression, but I think most of the widely used ones provide a way for avoiding this. For example, SqlDataConnection can read the setting from configuration file, other standard F# type providers allow specifying LocalSchemaFile that allows you to specify the necessary structure locally (e.g. *.dbml file for SQL).

The F# Data type providers can take URL to a remote file, but they can also take local file. So I think that there should always be a way to specify the information without specifying a constant connection string (etc.) - but feel free to ask about specific providers.

Baseboard

The links links "Please see Walkthrough: Accessing a SQL Database by Using Type Providers" are definitely broken on this page – Paralipomena

Nowadays it should support appSettings and env variables as well. ;-) Actually, I'd prefer to have some standard "protocol" which I need to implement in a separate assembly and then reference this assembly in TypeProvider. – Paralipomena