Migrate project to paket and FAKE

[eiriktsarpalis]

Migrates the project to make use of paket and FAKE. This should make it easier to manage dependencies as well as automate the testing/package authoring workflow. In the process I also switched from the obsolete PowerPack quotation evaluator to the FSharp.Quotations.Evaluator successor library. It should also make it easier to incorporate CI builds in Travis & AppVeyor in the future.

To build & run tests, simply run build.cmd or ./build.sh from the command line. To Release a new nuget package, run build.cmd Release or ./build.sh Release from the command line.

[daniel-chambers]

Cool, good idea to start using paket and FAKE; thanks for the PR. :) I've done a little testing on my machine and put some feedback below.

I'm seeing assembly version conflicts on FSharp.Core between 4.3.1.0 and 4.4.0.0 when the tests are run that cause them to fail when run through the build. This is caused by the app.config binding redirects in the integration tests redirecting to the wrong FSharp.Core version. I'm not sure why Paket is putting the wrong version in there. Maybe we need to explicitly take a dependency on FSharp.Core 4.3.1.0 in Paket (keeping in mind we should allow forwards compatibility with F# 4)?

The adoption of Paket has also quietly upgraded the version of WindowsAzure.Storage we build against (paket.lock shows 6.2.0 is the currently chosen version), even though we declare in paket.dependencies that we're good with 3.1+. At first blush this might not seem like an issue if 3.1 was compatible with 6.2, but 6.2 is formulating requests that make my (admittedly older) version of the Storage Emulator (3.4) to spit 400 Bad Request when running integration tests (after doing a temp hack fix here to bypass the previous issue). I'm not sure how we can declare we support 3.1+ if we're not actually building against 3.1 (we're just taking it on faith that we're not using anything in 6.2 that's not in 3.1, and with 3 major versions in between that's a bit scary), we either need to slide the minimum version forward, or move the build version back. Thoughts?

We should also gitignore all the working files, eg .fake\, paket-files\, xunit.html, so builds don't dirty up unstaged changes.

NuGet always created a SymbolSource NuGet package and published it alongside each version I push. Since Paket is now the one that is creating the NuGet packages, can we get it to create and push that too (it doesn't seem to be doing that now)? I assume SymbolSource is still a thing, the NuGet website still refers to it. Admittedly, I've never had much success with actually using SymbolSource as a symbol server in VS, so maybe it's not important anymore? I'm also open to maybe using SourceLink over our PDBs instead; a lot of FSharp projects seem to be doing that.

[isaacabraham]

The reason Paket has taken 6.2 is that the default behaviour is to get the most recent version of the package. If you want to pin Azure to a specific version, you can either mark it as e.g. = 3.1 or you can use the twiddle operator to use semver and never go above 3.x e.g. "~> 3.1".

I've seen issues with binding redirects and unit tests before, I'll have a look at the code this evening and see if this is the same thing.

[eiriktsarpalis]

Regarding your points:

• I've noticed this myself. When specifying redirects: on at the top of my paket.dependencies it always forces FSharp.Core to 4.4.0.0, regardless of what the target F# runtime is at the given project. Still, unit tests are working for me since I have F# 4.0 installed on my local computer. Any hints @forki ?
• By default paket will resolve the latest package version, up to constraints. My opinion is that this may be inappropriate in certain contexts, though I'm no sure how this could be overridden. @isaacabraham note that if we pin to a range using the twiddle operator, we also disallow the authored nuget package from referencing versions above that range.
• I'll incorporate a commit with the updated .gitignore.
• I've never used either SymbolSource or SourceLink, so not sure what exactly to do here.

[isaacabraham]

@eriktsarpalis The whole point is that if FSharp.Azure is only tested against 3.x and wants to prevent people using higher versions, them you want Paket to so people getting newer versions from other packages.

[daniel-chambers]

I don't think we should be preventing the use of the newer versions; the newer versions do actually work okay. The current constraint is fine, we just need to build against the minimum version, not the current version, to ensure we don't use new APIs.

What you think about SymbolSource @isaacabraham; do you know whether people still push packages there? On 7 Jan 2016 7:46 AM, "Isaac Abraham" notifications@github.com wrote:

@eriktsarpalis The whole point is that if FSharp.Azure is only tested against 3.x and wants to prevent people using higher versions, them you want Paket to so people getting newer versions from other packages.

— Reply to this email directly or view it on GitHub https://github.com/fsprojects/FSharp.Azure.Storage/pull/17#issuecomment-169456240 .

[isaacabraham]

Ah, I see where you're coming from now re: NuGet versions - to allow people to use any future version they want but to ensure backwards compatibility with 3.1. OK - not sure how to do that within Paket (or Nuget either) except maybe through Groups cc: @forki.

No idea about SymbolSource - sorry :-/

[eiriktsarpalis]

After consulting with @forki I've pushed some changes that should help address issues 1 & 2. Please review.

[daniel-chambers]

Thanks for the fixes, works well now! :)

I'm going to not worry about the SymbolSource thing. Seems like people don't use it, and it doesn't seem to be a Paket thing anyway.