Dotnetcore build for Paket.Core #1785

matthid · 2016-07-02T13:58:01Z

TODO (this PR):

Mono.Cecil (make it compile with latest changes (with netstandard1.5) jbevain/cecil#269)
Argu (Core clr support. Argu#57)
Chessi (update dnc support to preview2 tooling and RTM packages. Chessie#47)
AssemblyReader from FSharp.TypeProviders.StarterPack (make AssemblyReader compatible with dotnetcore FSharp.TypeProviders.SDK#110)
Make it build with dotnet build -f net46
Make it build with dotnet build -f netstandard1.6
'portable-win81+wpa81' should be compatible with everything greater netstandard1.2 (currently the condition is generated for netstandard1.2 only)!
Add to build

TODOs -> Later, see #1909

smoothdeveloper · 2016-07-02T14:20:02Z

@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.

matthid · 2016-07-02T14:30:51Z

@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!

Install the .NET Core SDK for Windows (from http://dot.net)
Clone this branch
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.

smoothdeveloper · 2016-07-02T20:07:35Z

@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.

matthid · 2016-07-03T21:52:48Z

@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 :(

matthid · 2016-07-10T16:12:06Z

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.

matthid · 2016-07-10T16:12:23Z

src/Paket.Core/InstallModel.fs

@@ -400,7 +438,7 @@ type InstallModel with

    member this.AddTargetsFiles targetsFiles = InstallModel.addTargetsFiles targetsFiles this

-    member this.AddPackageFile (path, file, references) = InstallModel.addPackageFile path file references this
+    //member this.AddPackageFile (path, file, references) = InstallModel.addPackageFile path file references this


Strictly speaking this was a public API, but it wasn't used anywhere and I'd like to get rid of it because it doesn't consider the new "ref" folder.

matthid · 2016-07-10T17:07:51Z

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 :(

matthid · 2016-07-10T18:25:36Z

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

matthid · 2016-07-10T19:31:35Z

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...

matthid · 2016-07-10T21:36:18Z

Yeah everything is green again.

forki · 2016-07-12T09:41:21Z

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?

matthid · 2016-07-12T10:08:07Z

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

forki · 2016-07-12T15:19:33Z

I think I already picked 1650f39 by accident.

matthid · 2016-07-12T19:38:42Z

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...

matthid · 2016-07-12T20:18:35Z

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

forki · 2016-07-21T14:50:16Z

chessie 0.6 should work on coreclr

matthid · 2016-07-22T19:39:00Z

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

forki · 2016-09-04T16:39:18Z

seems to work. now:

forki · 2016-09-04T16:44:03Z

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

matthid · 2016-09-04T16:45:19Z

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?

forki · 2016-09-04T16:45:47Z

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

matthid · 2016-09-04T16:48:02Z

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

forki · 2016-09-04T16:48:44Z

I just added it and now things work

matthid · 2016-09-04T16:49:24Z

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

forki · 2016-09-04T16:50:19Z

that whole concept is nuts, but yes

forki · 2016-09-04T17:02:59Z

so now I have broken integration tests!?

matthid · 2016-09-04T17:04:54Z

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

forki · 2016-09-04T17:05:52Z

ok will investigate tomorrow

enricosada · 2016-09-05T10:07:18Z

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

forki · 2016-09-05T10:08:50Z

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

forki · 2016-09-05T10:09:19Z

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

enricosada · 2016-09-05T10:11:08Z

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

forki · 2016-09-05T10:15:33Z

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

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

enricosada · 2016-09-05T10:26:27Z

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)

forki · 2016-09-05T10:27:49Z

otherwise is default fallback (no dependencies)

which would be wrong as well.

enricosada · 2016-09-05T10:31:08Z

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

enricosada · 2016-09-05T11:19:21Z

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

enricosada · 2016-09-05T11:37:38Z

@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>

matthid · 2016-09-05T12:44:14Z

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

matthid · 2016-09-05T12:47:00Z

@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.

enricosada · 2016-09-05T13:05:55Z

@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=%CD%\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

enricosada · 2016-09-05T13:08:11Z

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

enricosada · 2016-09-05T13:32:51Z

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

forki · 2016-09-07T14:54:16Z

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

enricosada · 2016-09-07T15:43:05Z

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

matthid mentioned this pull request Jul 2, 2016

FAKE 5 fsprojects/FAKE#1281

Closed

58 tasks

Martin-Bohring referenced this pull request in mcpride/EventSourcing-Infrastructure Jul 2, 2016

HintPath to packages more generalized

c4a64c7

matthid reviewed Jul 10, 2016
View reviewed changes

matthid force-pushed the dotnetcore branch from 0b29d9c to f76cfc6 Compare July 10, 2016 19:31

matthid mentioned this pull request Jul 11, 2016

Not able to use net20 library in net461 project #1779

Closed

forki added a commit that referenced this pull request Jul 12, 2016

Merge rest of #1785

f3cd126

mrinaldi mentioned this pull request Jul 12, 2016

Fixes #1783 #1784

Merged

matthid force-pushed the dotnetcore branch 2 times, most recently from 0e2315c to d489014 Compare July 12, 2016 20:13

ctaggart mentioned this pull request Jul 15, 2016

support for .NET Core and Portable PDB files ctaggart/SourceLink#121

Closed

matthid force-pushed the dotnetcore branch from d489014 to 7eb448b Compare July 19, 2016 19:25

matthid force-pushed the dotnetcore branch from 7eb448b to 80b27e9 Compare July 22, 2016 17:46

forki merged commit ad98edb into fsprojects:master Sep 5, 2016

matthid mentioned this pull request Nov 1, 2016

DotnetRestore target failed during build #1995

Closed

Dotnetcore build for Paket.Core #1785

Dotnetcore build for Paket.Core #1785

Conversation

matthid commented Jul 2, 2016 • edited Loading

smoothdeveloper commented Jul 2, 2016

matthid commented Jul 2, 2016

smoothdeveloper commented Jul 2, 2016

matthid commented Jul 3, 2016

matthid commented Jul 10, 2016

matthid Jul 10, 2016

Choose a reason for hiding this comment

matthid commented Jul 10, 2016

matthid commented Jul 10, 2016

matthid commented Jul 10, 2016

matthid commented Jul 10, 2016

forki commented Jul 12, 2016

matthid commented Jul 12, 2016

forki commented Jul 12, 2016

matthid commented Jul 12, 2016

matthid commented Jul 12, 2016

forki commented Jul 21, 2016

matthid commented Jul 22, 2016

forki commented Sep 4, 2016

forki commented Sep 4, 2016

matthid commented Sep 4, 2016

forki commented Sep 4, 2016

matthid commented Sep 4, 2016

forki commented Sep 4, 2016

matthid commented Sep 4, 2016

forki commented Sep 4, 2016

forki commented Sep 4, 2016

matthid commented Sep 4, 2016

forki commented Sep 4, 2016

enricosada commented Sep 5, 2016

forki commented Sep 5, 2016

forki commented Sep 5, 2016

enricosada commented Sep 5, 2016

forki commented Sep 5, 2016

enricosada commented Sep 5, 2016 • edited Loading

forki commented Sep 5, 2016

enricosada commented Sep 5, 2016

enricosada commented Sep 5, 2016 • edited Loading

enricosada commented Sep 5, 2016

matthid commented Sep 5, 2016

matthid commented Sep 5, 2016

enricosada commented Sep 5, 2016 • edited Loading

enricosada commented Sep 5, 2016

enricosada commented Sep 5, 2016

forki commented Sep 7, 2016

enricosada commented Sep 7, 2016 • edited Loading

matthid commented Jul 2, 2016 •

edited

Loading

enricosada commented Sep 5, 2016 •

edited

Loading

enricosada commented Sep 5, 2016 •

edited

Loading

enricosada commented Sep 5, 2016 •

edited

Loading

enricosada commented Sep 7, 2016 •

edited

Loading