@matthid this is awesome! would you mind posting here simple steps (from scratch, assuming I don't have dotnet.exe installed) to try it out?

I'd like to do some guinea pig testing on this, and could contribute to the documentation while you work on the heavy implementation stuff.

@smoothdeveloper Sure, but please keep in mind that I'm currently only interested in the netstandard1.6 package -> To test it in the FAKE branch. Therefore I'm (for now) ignoring other stuff. But please just go ahead and report issues!

1. Install the .NET Core SDK for Windows (from http://dot.net)
2. Clone this branch
3. Enter in git bash

cd src/Paket.Core.netcore
dotnet restore
dotnet build -f net46

You currently cannot run it. To run it one needs to convert the Cli project as well (which I don't need for now). A working Argu package can be found in my Fake branch (fsprojects/FAKE#1281) ... Besides that I think no further dependencies are needed. Conversation would be simply copying the project.json from Fake.netcore and updating dependencies and the compile-file list.

@matthid HttpClient stuff sounds like great fun!

I'm working on refactorings in ScriptGeneration.fs internals, if you'd need to change this for some reason, please keep it commented for now, working on new feature which I should have a small PR for soon.

@forki I think the netstandard stuff was broken, could you review 1df0579 ?

Can we somehow specify that a portable package is only compatible in the other way? IE I think they should not (at least not by default) be added when compiling a NetStandard library. On the other hand when compiling for Portable you can add portable profiles. I tried this But it seems like its the wrong direction :(

I made the following changes:

• Sort references by LibPath name (to make the order more stable across paket versions)
• Get rid of a unnecessary parenthesis for net40 (edge case because of net40-client)
• Import portable packages in NetStandard builds (currently we don't really need it in the project file, but I need it in FAKE for figuring out the correct references for the FSharp.Compiler.Service)

A careful review would be appreciated. I added a couple of tests for the new behavior.

I have no idea what AppVeyor and Travis are trying to tell me, locally all tests are working. Any idea what might be wrong? I cannot reproduce :(

I managed to write a failing unit test (which of course is not failing on my local machine)...

Oh my god. Problem is 15256bd which is not contained in my changes jet. But AppVeyor and Travis are building the merged state :(. This took me quite some time to realize...

Yeah everything is green again.

I cherry picked from this like crazy and tried to get everything in that is unrelated to .NET Core. Can you please rebase and take a look?

you should cherry pick 1650f39 as well . I try to take a closer look later...

I think I already picked 1650f39 by accident.

Wow I'm trying to get this back to a mergeable state.

Next time we should find a better workflow. Just force me to send smaller PRs (even if its not ideal for me as I'm finding all these things while trying to focus on one huge thing). Locking over the commits I see that some have been applied only partially so I might miss some things now. Or we could have just merged the whole thing (all tests were green anyway, just the testing of the dotnetcore stuff wasn't there). I think suggesting cherry picking wasn't a good suggestion on my part after all...

Anyway congrats that you managed to make a release of all of this and extracting the hidden pieces :).
Will take a closer look at the weekend and trying to get this back up now...

Hm maybe it wasn't as bad as expected :)
Only 3 conflicts and it still compiles...

chessie 0.6 should work on coreclr

@forki Thanks, using chessie 0.6 now and removed the old binaries

seems to work. now:

we need a nuge.config that clears all inherited crap, right?

Doesn't exactly look like its working though.

we need a nuge.config that clears all inherited crap, right?

I have no idea. @enricosada says no nuget.config is needed, correct?

you always want to delete the crappy machine wide config ;-)

I'm not against it but didn't I just delete one after the review?

I just added it and now things work

Ok good to know :) So we should always have one basically.

that whole concept is nuts, but yes

so now I have broken integration tests!?

No idea on CI and on my machine everything seems to work...

ok will investigate tomorrow

no nuget.config is needed, all packages are on nuget.org.

Sry for be late, anyway @forki as a note, to use dotnet sdk you can also use binaries (zip) instead of installer (msi). In every os.

a dotnet core sdk install is just

• download binaries
• unzip in a directory
• add that directory to PATH

like that it you doesnt mess with your machine (it's just a directory) and you can also use multiple version in parallel

The build script does just that (download unzip).

binaries are in the too much hidden Others download in http://dot.net core homepage -> https://www.microsoft.com/net/download#core

no nuget.config is needed, all packages are on nuget.org.

no we need the tag. othwerwise the package feeds from machine settings are used. which are wrong on my machine

btw: it's merged and released! Thanks for this amazing work

ah ok, better!
i was just saying the dotnet core f# must not use dev feed for dotnet core (otherwise version are bad)

Something is wrong: https://www.nuget.org/packages/Paket.Core

Paket.Core should not depend on FSharp.Core alpha for normal .NET

is not depending FSharp.Core for normal dotnet

    <dependencies>
      <group targetFramework=".NETStandard1.6">
        <dependency id="System.Xml.XmlDocument" version="[4.0.1, )" />
        <dependency id="System.Net.Requests" version="[4.0.11, )" />
        <dependency id="System.Diagnostics.TraceSource" version="[4.0.0, )" />
        <dependency id="System.Xml.XPath.XmlDocument" version="[4.0.1, )" />
        <dependency id="System.Diagnostics.Process" version="[4.1.0, )" />
        <dependency id="System.Xml.XDocument" version="[4.0.11, )" />
        <dependency id="System.Xml.XPath.XDocument" version="[4.0.1, )" />
        <dependency id="System.Security.Cryptography.ProtectedData" version="[4.0.0, )" />
        <dependency id="System.Security.Cryptography.Algorithms" version="[4.2.0, )" />
        <dependency id="System.Diagnostics.FileVersionInfo" version="[4.0.0, )" />
        <dependency id="NETStandard.Library" version="[1.6.0, )" />
        <dependency id="Newtonsoft.Json" version="[9.0.1, )" />
        <dependency id="FSharp.Core" version="[4.0.1.7-alpha, )" />
        <dependency id="Mono.Cecil" version="[0.10.0-beta1-v2, )" />
        <dependency id="Chessie" version="[0.6.0, )" />
      </group>
    </dependencies>

it does depende on FSharp.Core only for netstandard1.6 otherwise is default fallback (no dependencies)

otherwise is default fallback (no dependencies)

which would be wrong as well.

let me try locally why merge doesnt work as expected. it shoudl create a fallback <group> with previous deps

ok trying.
atm i got the same error as @forki

DotnetRestore task is resolving the wrong path for dotnet.exe, and it's using an old version of dotnet sdk

i have

e:\github\Paket>where dotnet
C:\dotnetcli\dotnet-dev-win-x64.1.0.0-preview2-003121\dotnet.exe
C:\Program Files\dotnet\dotnet.exe

and it's using C:\Users\e.sada\AppData\Local\Microsoft\dotnet\dotnet.exe instead

@forki built locally is ok.

temp/Paket.Core.3.19.0.nupkg the nuspec

    <dependencies>
      <group>
        <dependency id="Chessie"></dependency>
        <dependency id="FSharp.Core"></dependency>
        <dependency id="Mono.Cecil"></dependency>
        <dependency id="Newtonsoft.Json"></dependency>
      </group>
      <group targetFramework=".NETStandard1.6">
        <dependency id="System.Xml.XmlDocument" version="[4.0.1, )"></dependency>
        <dependency id="System.Net.Requests" version="[4.0.11, )"></dependency>
        <dependency id="System.Diagnostics.TraceSource" version="[4.0.0, )"></dependency>
        <dependency id="System.Xml.XPath.XmlDocument" version="[4.0.1, )"></dependency>
        <dependency id="System.Diagnostics.Process" version="[4.1.0, )"></dependency>
        <dependency id="System.Xml.XDocument" version="[4.0.11, )"></dependency>
        <dependency id="System.Xml.XPath.XDocument" version="[4.0.1, )"></dependency>
        <dependency id="System.Security.Cryptography.ProtectedData" version="[4.0.0, )"></dependency>
        <dependency id="System.Security.Cryptography.Algorithms" version="[4.2.0, )"></dependency>
        <dependency id="System.Diagnostics.FileVersionInfo" version="[4.0.0, )"></dependency>
        <dependency id="NETStandard.Library" version="[1.6.0, )"></dependency>
        <dependency id="Newtonsoft.Json" version="[9.0.1, )"></dependency>
        <dependency id="FSharp.Core" version="[4.0.1.7-alpha, )"></dependency>
        <dependency id="Mono.Cecil" version="[0.10.0-beta1-v2, )"></dependency>
        <dependency id="Chessie" version="[0.6.0, )"></dependency>
      </group>
    </dependencies>

@enricosada not sure if we should always use path or always install our own version. I tend to always install...

@forki yes the version you uploaded seems to be the netstandard version only? maybe temp/dotnet got uploaded first? no idea what paket push is doing there.

@matthid about dotnet location, we should use the dotnet in PATH.
that's the expected behaviour and it's the best one.
It should be an explicit action by user, if they dont have dotnet sdk installed (like in travis).
It's not good ihmo to install always, because it take time, and i already have dotnet sdk installed (it's a dependency, like every sdk)

i think the flow should be

install steps..

• fake InstallDotnetcore ./dotnet_sdk_dir to only install the sdk to specific directory
• add to PATH, like set PATH=�%\dotnet_sdk_dir;%PATH%

And normally

• fake normalbuild

fake should always expect that dotnet exists and is in PATH, that's the behaviour of all normal console app, works xplat.
obv fake can run dotnet --version to check if exists, otherwise stop build if it's required

@matthid yes it's the wrong package (the netcore), probably the publish is sending the wrong package

@forki sent pr #1911 to delete temp dotnetcore nuget packages before paket push

this is weird. this was green, but the mono build is still red after merge because of issue with dotnet core installation

let me fix that, is easy now instal netcore, ref #1914