WIP migrating to Azure Storage SDK 10.0 #129
Conversation
|
@xperiandri firstly thank you for creating this PR and apologies (I know we've spoken already about this) for the delay in getting to it. At first glance, is there a reason why we need to move to three separate type providers? What are the benefits from both the user's point of view as well as development experience? |
|
@xperiandri I've picked up where I left off with the TP - basically the latest versions of F# have build issues relating to the use of the FSharp Compiler Tools dependency (which is coupled to F#4.1) so I'm removing that dependency, whilst also upgrading to FAKE 5. Once they're both out of the way (hopefully today) let's work together to get this ready to go in - I'm willing to split out into three assemblies as long as it's clear what the benefits are. |
|
Sounds good |
|
@xperiandri where? I'm just getting the current couple of branches merged into master and then will start looking at this PR in more detial. |
# Conflicts: # .paket/Paket.Restore.targets # build.fsx # paket.dependencies # paket.lock
|
OK |
|
By the way, I would prefer to move to a model where you can create a provider with a connection string. |
|
@xperiandri you can already do that? |
|
I mean dynamically. Now you either pass it into TP in code, or when calling a method |
|
So move away from method-based overrides to a single override at the "top" level? That's something I'd love to do. (btw you can specify a config file as well). |
|
Yes. Cool! |
|
Regarding get executing assembly vs current assembly using a type - both should work; is there any difference? |
|
I guessed that it will fix an issue with that you need to have Tables.json in all project referencing project with type provider |
|
I've rebased my changed on top of yours |
No description provided.