fsprojects
WIP migrating to Azure Storage SDK 10.0
@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 Was I wrong changing getting current executing assembly to getting current assembly?
@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.
By the way, I would prefer to move to a model where you can create a provider with a connection string. Like ExcelProvider does.
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).
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