[Question] How to best handle resolution path for dynamic dll loading?

[Vidarls]

I would normally want ot use the same directoy as the current app is deployed to:

let path = Assembly.GetAssembly(typeof<TypeInMyAssembly>).CodeBase |> Path.GetDirectoryName

Of course the SqlDataProvider requires literals because it creates a compile / design time type.

My question is: What is the right way (tm) to do this in order to avoid hard coded requirements to DLL placements?

[pezipink]

There is no way to avoid this, the type provider at compile time must have a known connection string so that it can go off and provide the types. You are alternatively able to use a pre-defined connection string from the app.config file of your project (if you look at the static parameters, you will see one is named connectionStringName or similar, you can use that instead).

The general usage of the type provider is as follows;

1) Literal or config based connection string is used to connect to a database that your build environment can see, eg your dev database via the static parameters.

2) Runtime connection strings are passed to the overloaded GteDataContext() method, these connection strings can come from anywhere at runtime, and will be used to connect to your production database(s)

Hope that makes sense, let me know if you have any problems.

[pezipink]

Oh, I completely mis-read your question! At the moment there is no real way to avoid this, there is some work underway to basically split the providers apart and not use the dynamic loading but it is not done yet.

We can probably add something somewhere though which lets you pass a different resolution path at runtime ..

[Vidarls]

We did this for the Simple.Data mysql provider,where we mandate that Mysql.Data.dll must be in the same folder as the referring assembly. Check out https://github.com/Vidarls/Simple.Data.Mysql/blob/master/Src/Simple.Data.Mysql/MysqlConnectorHelper.cs.

Don't know if the way type providers work adds constraints not allowing such an approach, or if there are valid use cases where hard coding the dll path will be better.

I do recommend using dynamic loading for the db specific connectors, rather than hard references to specific versions. At least for MySql as there are cases where a particular db version works best with a specific connector version.

[pezipink]

We could add try various fallback resolution strategies if the first one fails - as a short term solution for you, just change the code around in this area to attempt your alternate resolution strategy.

https://github.com/fsprojects/SQLProvider/blob/master/src/SQLProvider/Providers.MySql.fs#L22 .

[Vidarls]

Ok, thank you for following up on me.

I had to do without the SqlProvider yesterday, but I hope to get some time to experiment some more in the future.