-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow optionally not requiring explicit connection strings #234
Comments
The most useful and only needed constructor in my opinion would be |
@isaacabraham Sorry for troubles. I knew it's going to be painful. :( |
@dmitry-a-morozov Hi! In our project code, the TP connection string is the config style one (rather than explicit connection). What we're currently doing is compiling our F# projects, and then referencing the output DLL in an F# script (rather than manually referencing all the .fs files). The problem is that once you do this, the TP looks in fsi.exe.config to resolve the connection string, rather than the config file of the project. So when (on occasion) we need to call our code from a script (testing, exploratory development etc.), we used to resort to manually changing the connection string from a config one to an explicit connection string. Now, this is no longer applicable because all our code stops compiling as soon as we change the connection string format. I'm open to suggestions on a "better way" to get to our code through scripts as well though! But at the same time - changing the structure of a string literal like this and have it change the provided type signatures is, whilst powerful, a little hidden - I spent a few hours with a colleague of mine trying to figure out why our code was behaving differently! |
I apologize again that I caused troubles. Something at my defense
|
I understand - you don't have to apologise! And yes, it was documented :-) And yes, appreciate your work on the other side - fsx files etc. Would it be possible to have an argument that's passed in to select the behaviour of the TP? I don't mind if the default is the "new" way - but at least giving us the option of reverting to the old behaviour would be really great. |
Let's tackle this from different perspective.
System.Environment.CurrentDirectory <- __SOURCE_DIRECTORY__ at beginning of each script Let me know what you thoughts. |
Either of those solutions would work for me - I think I prefer the second as it's probably what one would expect to happen anyway i.e. re-use the captured connection string. Can you think of any situations where that wouldn't be the expected behaviour? The first suggestion is probably more configurable - it allows you to redirect to another config file at script-time - but it's not entirely clear to me what the best working process / practice for that would be. Should the config file live in the script folder? Should you set the CD to the location of a config file? |
I can imagine situation when assembly was compiled somewhere else like CI server and you pull it down from let's say local nuget feed. It might have unexpected connection string value. But this is mostly speculation. |
Works for me :) |
Hi, //cc @smoothdeveloper Please help to test this release. |
All works - great. I did notice that we seem to now need to reference System.Runtime.Caching though? |
Good. |
Seems I may have been wrong - I don't think that this is quite working. I'm getting: -
when I execute a script that references a DLL with the TP (via #r). Not sure why. Here's the line that goes pop: - It looks like the first .Value passes, but the second fails. |
It might also be useful to see which file it's trying to reference. |
@isaacabraham I deployed 1.8.3-beta2. Speaking of #234 (comment) |
I'll upgrade to beta2 - maybe that was just in the first beta. |
I see the same issue in 1.8.3-beta2. The app.config connection string value is not retained for use in FSI. I get a 'KeyNotFoundException'. Adding the connection string to the' FsiAnyCPU.exe.config' solves the problem, so it is definitely still looking there. |
Fixed. |
@isaacabraham |
@dmitry-a-morozov I've just tried 1.8.3-beta3 - still doesn't work I'm afraid :-( It's still looking at the FSI config file. |
I take it back - just tried and it does work! |
Question: which project does it "pull" the connection string from?
|
Good questions. |
@dmitry-a-morozov last question. Post-build, is there a way to override the connection string that the TP uses? :-) Sometimes after we build after a specific connection string, we want to change this afterwards. If it's a non-starter, that's fine - but if it's possible, let me know and I'll open a separate issue for that. |
Well I guess that's where explicit connection strings become handy again. :) |
@isaacabraham are we happy with how connection strings (explicit or not) are handled now in the library? |
@smoothdeveloper Hey. I haven't touched this in a long time - I think we worked around (or with it) in some way - @theprash did we fix those issues with the SQL TP and F# scripts in the end? |
Description
In the latest release of SQLClient, behaviour changed so that if you supplied a connection string as the literal (rather than the named config value), all the provided types would request an explicit connection string.
Whilst I understand why this has been done, for us it's a real problem as we use named connection strings but occasional want to test with a real one. The TP should allow you to revert back to the old behaviour whereby it won't change the signatures of the generated types simply based on the contents of the literal.
The text was updated successfully, but these errors were encountered: