Support .NET Core

[asherber]

This takes #130 and incorporates the better project structure from @Gorniv in #136. Still to be resolved is the fate of MailMessage parsing, per our earlier discussion.

[asherber]

I think the Travis build is failing only because it's not set up to compile .NET Standard projects; there are related error messages in the log. I'm not sure how @Gorniv's branch is building – maybe he's excluding the new library from his build configuration?

[asherber]

Oh, I see – he's got two different solutions, so Travis isn't trying to build the NET Standard one. I think there are advantages to keeping the projects in a single solution, and building this will require teaching Travis about .NET Core anyway.

[darrencauthon]

DotNet.Props?

[asherber]

That's added by the tooling when you create a new .NET Standard library, part of the .xproj.

[asherber]

I added the dotnet restore that @Gorniv suggested, but it looks like Travis isn't doing anything with this branch currently.

[asherber]

... and from #136 it looks like Travis doesn't know how to do dotnet restore anyway, so nevermind! (I don't really have experience with Travis, so I'll leave it to the experts to work out.)

[Gorniv]

i fix travis.yml for dotnet core in my repository.

[asherber]

@darrencauthon With @Gorniv showing the way, I fixed up travis.yml to build things correctly. But in the last failing build, Travis is trying to do

nunit-console src/SparkPost.Tests/bin/Release/SparkPost.Tests.dll

even though the travis.yml I committed has

nunit-console src/SparkPost.Tests/bin/ReleaseNet45/SparkPost.Tests.dll

Any idea why this is happening, or maybe how to get Travis to flush its cache and try again?

[Gorniv]

why are you change Release/ReleaseNet45?

[asherber]

@Gorniv I have a single solution file. If Travis builds the Release configuration with mono, it will fail because the solution includes the NET Standard project (mono can only build Framework projects). So I created a second Release configuration that does not include the Standard project for building. I think this is cleaner than a second solution file just for the NET Standard project.

[asherber]

Passing! Just needed to get Travis to try again.

@darrencauthon When I made the appropriate changes to the nuspec in 06594, Github couldn't figure out the conflicts. I put them here in a Gist, so you can apply directly to master: https://gist.github.com/asherber/fd91ced09a9a201d0126c8bb4c31ffca

Note that I moved the nuspec up to the src folder, since it draws from two subprojects. The project.json changes reinstate the XML docs but then also turn off the warning for members where they are missing.

[darrencauthon]

Thank you guys for your work on this, I'll look at this in more detail when my week's work is done and I'm on weekend break.

[Jetski5822]

I assume we will now need to change to use the csproj stuff now? as the project.json is obsolete. :(

[asherber]

I wouldn't call project.json obsolete – it is still fully supported for building .NET Standard assemblies in VS2015. In fact, it's the only way to do it in VS2015. So I think there's no immediate rush to convert to VS2017/csproj, but I also think it's an easy conversion once Darren decides to switch.

[ajbeaven]

Can we get this merged please?

[asherber]

@darrencauthon At this point we would need to merge in recent changes and also decide whether to keep the .NET Standard stuff in VS2015 format or move it to VS2017. I've moved all my personal Standard things to VS2017, but I'm not sure if we'll run into issues again with Travis etc.

[darrencauthon]

VS2017. Working on this now..

[pedershk]

Is this coming along at all? Been a while since the last update :)

[jboarman]

How safe is the state of this PR for me to just pull it down and use it as-is in a side solution until the official package provides Core support?