* Use platform detection that works on mono 4.6+
* Move to use package reference for restoring nuget packages.
* DateTimeRoutines does not have Nuget packages that support .NET Standard (and therefore .NET Core). We will have to include them for now until we can get rid of this dependency.
* Start spliting some interfaces into their own files - this will help by allowing us to split them out in the future into a seperate project so the actual implementations can stay within their respective architectures when required
* Move out common libraries
* Few more tidy up tasks to get things working with .NET Standard
* Restructure the solution layout
* Encoding work to reduce rework later on platforms without Windows codepages (or require compliance with RFC1345)
* Move folder structure around to have more natural layout of the solutions
* DI server configuration to get rid of "temporary" hack and dependency circle for serverservice
* Make all encoding consistent to match the expected encoding casing for earlier versions of mono.
* Move to use package reference for restoring nuget packages.
* Return a task result for this async method.
* Update to a supported version of the .NET Framework. This also has the side effect of allowing us to automatically generate our binding redirects on build.
* Set the solution to target VS2017
* Update test solution csproj file to support being built through MSBuild 15
* Move to use package reference for restoring nuget packages.
* Return a task result for this async method.
* Update to a supported version of the .NET Framework. This also has the side effect of allowing us to automatically generate our binding redirects on build.
* Set the solution to target VS2017
* Update test solution csproj file to support being built through MSBuild 15
* DateTimeRoutines does not have Nuget packages that support .NET Standard (and therefore .NET Core). We will have to include them for now until we can get rid of this dependency.
* Move the interfaces into their own files. This will be useful when we share them between the .NET Core and .NET Framework WebAPI
* Stage services that need to point to the new interface namespace.
* Update CurlSharp to fix memory leak issue and support better runtime compatibility with OSX and Linux
* Start spliting some interfaces into their own files - this will help by allowing us to split them out in the future into a seperate project so the actual implementations can stay within their respective architectures when required
Nathan Holland