Build to .NetStandard (#90)

[chrisw000]

This PR is from a new branch to one mentioned in #90 - as previously mentioned branch had loads of trial and error noise in the commit history.

Currently targets netStandard1.3, tests target net461; running correctly in visual studio and travis via command line.

netStandard1.3 output can be consumed by a framework 4.6+ application. Referencing the source code directly would require adding a nuget package reference to System.Net.Http v4.3.3

my #90 comments go on a bit... so feel free to just ask any questions?

[dougdellolio]

@jonnii mind helping me look at this?

[jonnii]

This and the assembly name is now inferred from the project name (which is nice).

[jonnii]

FWIW other than the build stuff this looks pretty good to me, I think the majority of your "problems" are from running the CI on travis... it's great, but I've had a much easier time in .net land using appveyor. Here's an example of a script which builds and versions packages using netcore/standard and gitversion.

I'm not 100% sure if it's even possible to get a net461 and netstandard (with multiple target frameworks) to work linux, I think you have to do that on windows. It may be easier to just target netstandard2.0 and be done with it... that may be the easiest quickest way to resolve all these issues.

[jonnii]

e.g. if you did this https://docs.travis-ci.com/user/languages/csharp/#.NET-Core you could create a matrix build for netcore2.0 and netcore2.1...

[chrisw000]

Updated; now building net461 & netstandard2.0 + running tests for each.

I'll take a look at what @jonnii linked to tomorrow to see if there is a better or alternative way ahead

[chrisw000]

Travis Build
I've looked at the matrix concept. The matrix builds an array of parameters, with one build per unique combination of parameters, with builds running in parallel.

This doesn't help us too much, because the root of the issue is that we need to build and/or test the net461 DLL in a different way to the netcore DLLs. (different as in not just parameter changes executed the same way by the same script)

The dotnet command is part of the CLI toolset, and is separate from msbuild.

This vstest issue tracks what needs to be "fixed" in the CLI and/or msbuild tools, to address the root of the problem we're faced with.

I think where I've ended up is a reasonable solution.

We use msbuild to restore / generate the output.
We use mono to run the net461 tests using the command line runner
We use dotnet test (crucially with --no-build option) to run the netcoreapp2.0 tests

Visual Studio Build
Looking at the logs.... Test Explorer seems to only run the tests against the net461 dll. On my machine it fairly often fails with a non fatal Out of Memory error, when trying to discover tests after a build... but manually clicking "Run All" in Test Explorer always works.

It would be straightforward to run the netcoreapp2.0 tests via a command prompt with something similar to this; depending on what you need - with or without the --no-build flag
dotnet test GDAXSharp.Specs/GDAXSharp.Specs.csproj --no-build --configuration Debug--framework netcoreapp2.0

Building first time on dev box
The only other thing to note... the contents of the /obj folder are not compatible between the old csproj format build tools and the new ones.

Most likely, when you pull this new csproj you're going to have old format /obj contents.

If you don't delete /obj - you'll get strange compile errors and won't be able to build anything.

Further, if you're flipping between branches - and (say) /master is the new format csproj and /feature/xyz is the old format /obj --> you'll have to delete the /obj folders each time you swap over.

[jonnii]

Further, if you're flipping between branches - and (say) /master is the new format csproj and /feature/xyz is the old format /obj --> you'll have to delete the /obj folders each time you swap over.

Use git clean -fxd it is your friend in this situation.

What's the story with packaging and deploying a new version? Is that automated too? With the new tooling you can use dotnet pack and dotnet nuget push... the pack also takes care of the build for you too and puts everything in the right framework dependent subfolder.

[chrisw000]

Use git clean -fxd it is your friend in this situation.

cool... historically I've always used svn so these tips are great.

Re packaging... no idea... one for @dougdellolio. I've assumed its a manual process to date.

dotnet pack would need to be run with the --no-build flag, otherwise it will fail on Travis due to the linux / net461 framework issue. With --no-build it should be able to pickup the content from the msbuild step.

So... yeah... automating that part should be possible...

Question - how does that packaging / push to nuget work when people fork? For example, I've been running this build out of my fork, on travis... how does it stop those builds from getting pushed to NuGet ?

[chrisw000]

Although maybe packaging etc. should be a separate PR, which considers moving to Appveyor?

[jonnii]

So what I do on my own projects is this in appveyor:

deploy:
  provider: NuGet
  skip_symbols: true
  api_key:
    secure: Z1QcGBawSRfoLPWCtkhcZEMD4f+QLbw2o01T/BEuHL9hERKTSrVOutzAp8QCyDIf
  on:
    appveyor_repo_tag: true

The condition is to push to nuget when there's a new tag. Tags are used to control versioning, so you can create a release in github and it will automatically tag and push to github. This is controlled using gitversion. You can do something similar with travis i'm sure.

[chrisw000]

That makes sense.... but is that exposing the key which means anyone could mess with the nuget package and publish rouge releases?

[jonnii]

In appveyor that's an encrypted secret.

[dougdellolio]

all nuget releases I have done have been manual. I’d rather not release a package for every single merge for this project as I don’t think it’s necessary. Had busy day today so didn’t get a chance to look into appveyor and building there but will hopefully get to it tomorrow.

[jonnii]

@dougdellolio you can set it up so only the tagged or labelled releases get published, so you can pick and choose when along with seeing the diff between versions.

[dougdellolio]

@chrisw000 i have added a build to appveyor #130 . is there anything you want me to try or need me to do?

[chrisw000]

I believe it should "just work", merge it into /master if you're done and I'll pull into my branch

[chrisw000]

Travis failure due to it being unable to download a mono package. I don't think this has anything to do directly with this project - potentially a travis issue?

Fails with:
Failed to fetch http://download.mono-project.com/repo/ubuntu/pool/main/m/mono/mono-4.0-gac_5.12.0.226-0xamarin3+ubuntu1404b1_all.deb Connection failed

AppVeyor built and passed incredibly quickly.... that build output all looks good for .netStandard2.0 and net461 + 2 sets of tests passing.

Should I just remove the Travis file or do you want to keep both for now?

[dougdellolio]

nice! go for it. I can disable it if it still decides to run

[dougdellolio]

i tested this with an existing app and everything seems fine... i tried running tests through visual studio and get OutOfMemoryException. Resharper runs tests fine. any idea? otherwise I am ready to merge this

[chrisw000]

Yes, I mentioned this on the other thread. In Visual Studio, I got OutOfMemoryExceptions when it tries to auto discover the tests after a build.

If you click "Run all Tests" manually it will discover, run and pass all the tests OK.

[dougdellolio]

@chrisw000 thanks for all of your work here

[chrisw000]

actually... just noticed... the .sln file needs a minor tweak - remove the link to the travis file - and put in the appveyor file.... just to tidy it up.