This is a big set of changes I've been working on for the last couple of weeks to:
Support .NET Standard 2.0
Upgrade the build system to FAKE 5
Port the tests to Expecto
Run a Linux build using Travis and .NET Core
Fix a bug in fromTableAsync where the take count wasn't respected
It's all coming in a massive changeset because I found it much easier to start from scratch with an empty repo and create new .NET SDK F# projects targeting .NET Standard 2.0, then slowly bring across all the code. C'est la vie.
.NET Standard 2.0 Support
We now target .NET Standard 2.0. This enables us to support both .NET Framework as well as .NET Core. This has been a long time coming and finally fixes #27. Thanks for being patient!
The one caveat is that WindowsAzure.Storage does not support the synchronous API to table storage in their .NET Standard library (see https://github.com/Azure/azure-storage-net/issues/367). As a workaround, all the sync functions in this library are now sync-over-async implementations.
FAKE 5 Build System
The build script has been rewritten from scratch using FAKE 5.
Expecto Tests
The old tests were written in XUnit, which was okay except that it made it awkward to cleanly pass in the connection string to the storage account. Because Expecto tests are just function composition and running them is just a command line app with a proper entry point, it's easy to grab the connection string from an env var and pass it into the tests.
I also made some quality of life changes in there so that the tests can be run in parallel and properly clean up after themselves. You'll find that running them all is much faster than before, especially against a real table storage account.
Linux build on Travis and .NET Core
Thanks to now supporting .NET Core via .NET Standard 2.0, it's now trivial to run on Linux. So I've set up a Travis build so that we're building and testing there too.
Bugfix in fromTableAsync where the take count wasn't respected
While porting the tests I discovered a long-standing bug that meant the take count wasn't being respected when you used fromTableAsync if multiple segments were returned. Instead, you'd receive your take count of rows per segment. This has been fixed.
This is a big set of changes I've been working on for the last couple of weeks to:
fromTableAsyncwhere the take count wasn't respectedIt's all coming in a massive changeset because I found it much easier to start from scratch with an empty repo and create new .NET SDK F# projects targeting .NET Standard 2.0, then slowly bring across all the code. C'est la vie.
.NET Standard 2.0 Support
We now target .NET Standard 2.0. This enables us to support both .NET Framework as well as .NET Core. This has been a long time coming and finally fixes #27. Thanks for being patient!
The one caveat is that
WindowsAzure.Storagedoes not support the synchronous API to table storage in their .NET Standard library (see https://github.com/Azure/azure-storage-net/issues/367). As a workaround, all the sync functions in this library are now sync-over-async implementations.FAKE 5 Build System
The build script has been rewritten from scratch using FAKE 5.
Expecto Tests
The old tests were written in XUnit, which was okay except that it made it awkward to cleanly pass in the connection string to the storage account. Because Expecto tests are just function composition and running them is just a command line app with a proper entry point, it's easy to grab the connection string from an env var and pass it into the tests.
I also made some quality of life changes in there so that the tests can be run in parallel and properly clean up after themselves. You'll find that running them all is much faster than before, especially against a real table storage account.
Linux build on Travis and .NET Core
Thanks to now supporting .NET Core via .NET Standard 2.0, it's now trivial to run on Linux. So I've set up a Travis build so that we're building and testing there too.
Bugfix in
fromTableAsyncwhere the take count wasn't respectedWhile porting the tests I discovered a long-standing bug that meant the take count wasn't being respected when you used
fromTableAsyncif multiple segments were returned. Instead, you'd receive your take count of rows per segment. This has been fixed.