Added NETCore libraries, publish cmd

[kroniak]

This closes #61.

Summary: netcore dlls are packed into exist packages with bumping versions.

Changes:

• [updated] nuget.exe to produce NET Platform 5.4 target packages.
• [added] 2 xprojects for NET Platform 5.4 which compiles shared code.
• [added] publish.cmd. It auto builds packages on postbuild trigger.
• [edited] projects files to use publish.cmd
• [fixed] I have fixed eols and added .gitattribute file to prevent that situation for future.

I have tested packages on DNX projects, classic lib, portable lib.

[tmenier]

This is looking good. Sorry for the delays on my end - partly time constraints, partly just wanting to get up to speed on this stuff and understand it. Just to be clear, are we still at 2 separate NuGet packages?

I'm looking to Json.NET as an example of a library supporting all of the above platforms with a single NuGet package. Have a look at their nuspec. How can it be that simple? I feel like I'm missing something.

Anyway, I still intend to accept your PR at some point soon, I just want to get us down to 1 NuGet package (or understand why that's not possible). Thanks again - your contributions are greatly appreciated!

[kroniak]

There are not 2 separate packages, only Flurl and Flurl.Http.
Look in
Build/Flurl.Http.nuspec
Build/Flurl.nuspec

It is your two packages, which integrates NETCore dlls also like

<files>
        <file src="..\Flurl\bin\Release\Flurl.*" target="lib\portable-net40+sl50+win+wpa81+wp80+MonoAndroid10+MonoTouch10" />
        <file src="..\artifacts\bin\Flurl.NETCore\Release\dotnet5.4\Flurl.*" target="lib\dotnet5.4" />
    </files>

To build test packages before merge needs:

• clone my dev/dnx branch
• restore nuget packages for csproj.
• restore auto for Http xproj will be failed because there are not Flurl 1.1.0 nuget package.
• build Flurl project with Release. It produces Flurl 1.1.0 nuget.
• Test it youself and use it to restore packages in xproj http. You can add to sln root file nuget.config with this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="Local" value=".\Publish\" />
  </packageSources>
  <disabledPackageSources>
    <add key="Microsoft and .NET" value="true" />
  </disabledPackageSources>
</configuration>

• Build whole solution with release, it produces 2 packages in publish.
  It's all.

To build after merge needs:

• clone your repo master.
• restore nuget packages for csproj.
• restore auto for Http xproj will be failed because there are not Flurl 1.1.0 nuget package.
• build Flurl project with Release. It produces Flurl 1.1.0 nuget. Publish it to nuget.
• restore http xproj will be fine after it.
• build whole sln and publish packages.

It needs once time, there are not workaround to references csproj to xproj with different targets.

[tmenier]

Great. Avoiding having separate NuGet packages for .NETCore was my top concern. My next question is, can we get down to 2 targets instead of 3 (and avoid having 2 additional projects)?

Have you read this article?

https://oren.codes/2015/07/29/targeting-net-core/

The "Existing Libraries" section suggests to me that instead of 3 targets (net45, portable-*, and .NETPlatform5.4), we might be able to get by with 2 (portable-* and dotnet). The "Call To Action" section provides some additional details.

I'm not suggesting that we discard your new xproj projects, rather I'm wondering if we can discard my .NET 4.5 project and replace it with your new one. I'm not sure yet. Does that sound like it would work?

[kroniak]

I would not like to replace all non PCL targets to dotnet, because it pulls dependencies which not needed with many targets - net45+. These dependencies needs only for netcore (old dnxcore)

I can remove the Http.NET45 project and move the NET45 target to Xproj.

If you look in Json.net package you discover many target libs inside.

It is init xproj class library. Separate net45.

"frameworks": {
    "net451": { },
    "dotnet5.4": {
      "dependencies": {
        "Microsoft.CSharp": "4.0.1-beta-23516",
        "System.Collections": "4.0.11-beta-23516",
        "System.Linq": "4.0.1-beta-23516",
        "System.Runtime": "4.0.21-beta-23516",
        "System.Threading": "4.0.11-beta-23516"
      }
    }
  }

[kroniak]

Please review this PR ASAP and say your word about removing http.net45 project . I will modify some files in the PR.
Would like to close this question.

[kroniak]

@tmenier when will you upload the new version of packages?

[tmenier]

I'm going to upload a prerelease today and announce it on Twitter, so that we and anyone else who cares to can test it. I'll give you a heads up here as well - are you available to take one last look once it's up? I'd say if things are looking good I'll remove the "-pre" tomorrow. Thanks again for doing this, very much appreciated.

[tmenier]

Prereleases are up:
https://www.nuget.org/packages/Flurl/1.1.0-pre
https://www.nuget.org/packages/Flurl.Http/0.8.0-pre

[kroniak]

@tmenier

From my side all works with this pre version.

But before release final packages look #71.

[tmenier]

@kroniak Thanks! Quick question for you: I currently have 2 "PackageTester" projects in the solution that just exist for manually testing package downloads (one for .NET 4.5, one for PCL) to make sure all the right bits come down and everything builds. If I were to do the same for .NET Core, what would be a good project type to use?

[kroniak]

I use for this case DNX Lib with project.json like:

{
  "dependencies": {
    "Flurl.Http": "0.8.0-pre",
    "Flurl": "1.1.0-pre"
  },

  "frameworks": {//include all targets
    "net45": {},
    "dotnet54": {},
    "portable-net45+sl50+win+wpa81+wp80": {}
    }
}

And I use DNX lib project with this project.json to launch tests which are in shared project:

{
  "compilationOptions": {
    "warningsAsErrors": true
  },

  "configurations": {
    "Release": {
      "compilationOptions": {
        "optimize": true
      }
    }
  },

  "compile": [ "../Ecwid.Test.Shared/**/*.cs", "../../src/**/*.cs" ],
  "compileExclude": [ "../**/*RealTest.cs" ],

  "commands": {
    "test": "xunit.runner.dnx"
  },

  "dependencies": {
    "Flurl.Http": "0.8.0-pre",
    "Moq": "4.2.1510.2205",
    "xunit": "2.1.0",
    "xunit.runner.dnx": "2.1.0-rc1-build204"
  },

  "frameworks": {
    "dnx451": {
      "frameworkAssemblies": {
        "System.Net.Http": "4.0.0.0"
      }
    }
  }
}

[tmenier]

I'm about to drop the "-pre". Not worried about sl5, it's no more broken now than it was before. Do you have a Twitter handle? couldn't find you but would love to give you props for this.

[kroniak]

I don't use Twitter. But I have created https://twitter.com/kroniak.

I was discovering last commit and didn't understand what changed with version 1.1.1. Can you explain me?

[tmenier]

I packaged and uploaded Flurl 1.1.0 (necessary before I could do Flurl.Http 0.8), but then I was unable to install it into .NET Core projects. Not sure why but I assumed it was a packaging blunder of some sort and I wanted to fix it quickly before people started downloading it. The only way to do that once it's live on nuget.org is to up the version, so I did a 1.1.1 and tried again. It worked that time.

I think your publish script works fine as there were no issues with 1.1-pre or 1.1.1. Not sure what happened with 1.1.0 but I'm chalking it up as an anomaly.