New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dotnetcore build for Paket.Core #1785

Merged
merged 2 commits into from Sep 5, 2016

Conversation

Projects
None yet
5 participants
@matthid
Member

matthid commented Jul 2, 2016

TODO (this PR):

TODOs -> Later, see #1909

@matthid matthid referenced this pull request Jul 2, 2016

Closed

FAKE 5 #1281

58 of 58 tasks complete
@smoothdeveloper

This comment has been minimized.

Show comment
Hide comment
@smoothdeveloper

smoothdeveloper Jul 2, 2016

Contributor

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

Contributor

smoothdeveloper commented Jul 2, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 2, 2016

Member

@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 (fsharp/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.

Member

matthid commented Jul 2, 2016

@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 (fsharp/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.

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

@smoothdeveloper

This comment has been minimized.

Show comment
Hide comment
@smoothdeveloper

smoothdeveloper Jul 2, 2016

Contributor

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

Contributor

smoothdeveloper commented Jul 2, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 3, 2016

Member

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

Member

matthid commented Jul 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 10, 2016

Member

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.

Member

matthid commented Jul 10, 2016

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.

Show outdated Hide outdated 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

This comment has been minimized.

@matthid

matthid Jul 10, 2016

Member

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

matthid Jul 10, 2016

Member

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.

Show outdated Hide outdated src/Paket.Core/InstallProcess.fs
let assembly = LoadAssembliesSafe.reflectionOnlyLoadFrom library
Some (assembly, BindingRedirects.getPublicKeyToken assembly, assembly.GetReferencedAssemblies(), redirects, profile)
let assembly = Mono.Cecil.AssemblyDefinition.ReadAssembly(library)
Some (assembly, BindingRedirects.getPublicKeyToken assembly, assembly.MainModule.AssemblyReferences, redirects, profile)

This comment has been minimized.

@matthid

matthid Jul 10, 2016

Member

Was there a reason for not using Mono.Cecil until now? Everything still seems to work and the code looks "safer" now. But maybe there was a reason to use ReflectionOnlyLoadFrom?

@matthid

matthid Jul 10, 2016

Member

Was there a reason for not using Mono.Cecil until now? Everything still seems to work and the code looks "safer" now. But maybe there was a reason to use ReflectionOnlyLoadFrom?

Show outdated Hide outdated tests/Paket.Tests/ExtractPackageSpecs.fs
[<Test>]
let ``should report blocked download``() =
ensureDir()

This comment has been minimized.

@matthid

matthid Jul 10, 2016

Member

I added these to make the tests runnable from within visualstudio. NUnit 3 no longer sets the current directory. No idea if there is a better way to change this globally instead of adding ensureDir to every test... ?

@matthid

matthid Jul 10, 2016

Member

I added these to make the tests runnable from within visualstudio. NUnit 3 no longer sets the current directory. No idea if there is a better way to change this globally instead of adding ensureDir to every test... ?

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 10, 2016

Member

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

Member

matthid commented Jul 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 10, 2016

Member

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

Member

matthid commented Jul 10, 2016

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

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 10, 2016

Member

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

Member

matthid commented Jul 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 10, 2016

Member

Yeah everything is green again.

Member

matthid commented Jul 10, 2016

Yeah everything is green again.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 12, 2016

Member

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?

Member

forki commented Jul 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 12, 2016

Member

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

Member

matthid commented Jul 12, 2016

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

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

@mrinaldi mrinaldi referenced this pull request Jul 12, 2016

Merged

Fixes #1783 #1784

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 12, 2016

Member

I think I already picked 1650f39 by accident.

horse

Member

forki commented Jul 12, 2016

I think I already picked 1650f39 by accident.

horse

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 12, 2016

Member

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

Member

matthid commented Jul 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 12, 2016

Member

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

Member

matthid commented Jul 12, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 21, 2016

Member

chessie 0.6 should work on coreclr

Member

forki commented Jul 21, 2016

chessie 0.6 should work on coreclr

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 22, 2016

Member

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

Member

matthid commented Jul 22, 2016

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

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Aug 24, 2016

Member

If you're working towards a cross-platform http client, I wouldn't mind helping out to make https://github.com/haf/Http.fs support .Net core.

Member

haf commented Aug 24, 2016

If you're working towards a cross-platform http client, I wouldn't mind helping out to make https://github.com/haf/Http.fs support .Net core.

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Aug 24, 2016

Member

@haf To keep this PR simple I used HttpClient (which should work across the board) but I think a solution without #ifs would be preferable in the long run...
Regarding the Http.fs library, I think it looks nice and it would make sense to switch to it as part of this PR (if @forki agrees). However I'm not sure I have capacity to do it (those changes are really the minimal to make the "new" FAKE run). I didn't even manage to handle proxies properly as I didn't understand what the current code tries to achieve...

Member

matthid commented Aug 24, 2016

@haf To keep this PR simple I used HttpClient (which should work across the board) but I think a solution without #ifs would be preferable in the long run...
Regarding the Http.fs library, I think it looks nice and it would make sense to switch to it as part of this PR (if @forki agrees). However I'm not sure I have capacity to do it (those changes are really the minimal to make the "new" FAKE run). I didn't even manage to handle proxies properly as I didn't understand what the current code tries to achieve...

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Aug 24, 2016

Member

Regarding proxies. I have no idea. It's trying to work around Russian
firewalls I guess.

Am 24.08.2016 12:01 schrieb "Matthias Dittrich" notifications@github.com:

@haf https://github.com/haf To keep this PR simple I used HttpClient
(which should work across the board) but I think a solution without #ifs
would be preferable in the long run...
Regarding the Http.fs library, I think it looks nice and it would make
sense to switch to it as part of this PR (if @forki
https://github.com/forki agrees). However I'm not sure I have capacity
to do it (those changes are really the minimal to make the "new" FAKE run).
I didn't even manage to handle proxies properly as I didn't understand what
the current code tries to achieve...


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1785 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOGhkp67_ykO-w9tnsiG5BPFSid0ks5qjBZogaJpZM4JDrgC
.

Member

forki commented Aug 24, 2016

Regarding proxies. I have no idea. It's trying to work around Russian
firewalls I guess.

Am 24.08.2016 12:01 schrieb "Matthias Dittrich" notifications@github.com:

@haf https://github.com/haf To keep this PR simple I used HttpClient
(which should work across the board) but I think a solution without #ifs
would be preferable in the long run...
Regarding the Http.fs library, I think it looks nice and it would make
sense to switch to it as part of this PR (if @forki
https://github.com/forki agrees). However I'm not sure I have capacity
to do it (those changes are really the minimal to make the "new" FAKE run).
I didn't even manage to handle proxies properly as I didn't understand what
the current code tries to achieve...


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1785 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOGhkp67_ykO-w9tnsiG5BPFSid0ks5qjBZogaJpZM4JDrgC
.

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Aug 24, 2016

Member

Alright, well, I thought I should make the suggestion at least.

Member

haf commented Aug 24, 2016

Alright, well, I thought I should make the suggestion at least.

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Aug 24, 2016

Member

@haf From my side there I'm happy to accept a PR to this branch ;).
I think all this dotnetcore PRs will stay open until we have a proper FSharp.Core we can depend on.

Member

matthid commented Aug 24, 2016

@haf From my side there I'm happy to accept a PR to this branch ;).
I think all this dotnetcore PRs will stay open until we have a proper FSharp.Core we can depend on.

@matthid matthid changed the title from WIP: dotnetcore support. to Dotnetcore support. Sep 2, 2016

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 2, 2016

Member

I think this is ready after fsprojects/FSharp.TypeProviders.SDK#110 and restarting the builds (they should be green)

Member

matthid commented Sep 2, 2016

I think this is ready after fsprojects/FSharp.TypeProviders.SDK#110 and restarting the builds (they should be green)

@matthid matthid referenced this pull request Sep 2, 2016

Closed

TODOs to complete Dotnetcore Support #1909

0 of 12 tasks complete
@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 3, 2016

Member

So this should be ready for review/merge. After merging this the next Paket.Core nuget package release will have a netstandard binary. However it is packaged like the current Chessie (which is not as good as it could be IMHO) ie. missing a dependency group for net45. Main reason is that paket pack needs to be patched...

The main advantage is that after merging this no other PR will break netstandard support again... This is not full support but only the Core (we can do the rest one-by-one on demand, see #1909)

Member

matthid commented Sep 3, 2016

So this should be ready for review/merge. After merging this the next Paket.Core nuget package release will have a netstandard binary. However it is packaged like the current Chessie (which is not as good as it could be IMHO) ie. missing a dependency group for net45. Main reason is that paket pack needs to be patched...

The main advantage is that after merging this no other PR will break netstandard support again... This is not full support but only the Core (we can do the rest one-by-one on demand, see #1909)

Show outdated Hide outdated Paket.sln
@@ -1,11 +1,13 @@
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.31101.0
# Visual Studio 14

This comment has been minimized.

@forki

forki Sep 3, 2016

Member

mhm could you please revert that!? or is it needed?

@forki

forki Sep 3, 2016

Member

mhm could you please revert that!? or is it needed?

This comment has been minimized.

@matthid

matthid Sep 3, 2016

Member

done

@matthid
Show outdated Hide outdated lib/nuget/argu/3.0.0-beta02/argu.nuspec
<group targetFramework=".NETStandard1.6">
<dependency id="System.Xml.XDocument" version="[4.0.11, )" />
<dependency id="Microsoft.FSharp.Core.netcore" version="[1.0.0-alpha-160629, )" />
<dependency id="NETStandard.Library" version="[1.6.0, )" />

This comment has been minimized.

@forki

forki Sep 3, 2016

Member

do we need the full thing?

@forki

forki Sep 3, 2016

Member

do we need the full thing?

This comment has been minimized.

@matthid

matthid Sep 3, 2016

Member

Actually Argu is not required in this PR as Paket.Core doesn't need it. Nice catch. Should I squash everything to get rid of the binaries in the history?

@matthid

matthid Sep 3, 2016

Member

Actually Argu is not required in this PR as Paket.Core doesn't need it. Nice catch. Should I squash everything to get rid of the binaries in the history?

This comment has been minimized.

@forki

forki Sep 3, 2016

Member

yes please squash. /cc @ploeh ;-)

@forki

forki Sep 3, 2016

Member

yes please squash. /cc @ploeh ;-)

This comment has been minimized.

@forki

forki Sep 3, 2016

Member

also a rebase would be nice ;-)

@forki

forki Sep 3, 2016

Member

also a rebase would be nice ;-)

This comment has been minimized.

@matthid

matthid Sep 3, 2016

Member

Well usually I'm against squashing as well :). I could very well rework the history in another way to get rid of the binaries, but it's way more work ;) . I would say this is an extreme case as it hurts clone speed for no good reason...

@matthid

matthid Sep 3, 2016

Member

Well usually I'm against squashing as well :). I could very well rework the history in another way to get rid of the binaries, but it's way more work ;) . I would say this is an extreme case as it hurts clone speed for no good reason...

@@ -29,35 +29,78 @@ let [<Literal>] NuGetConfigFile = "NuGet.Config"
let [<Literal>] FullProjectSourceFileName = "FULLPROJECT"
let [<Literal>] ProjectDefaultNameSpace = "http://schemas.microsoft.com/developer/msbuild/2003"
#if DOTNETCORE
module internal Environment =

This comment has been minimized.

@forki

forki Sep 3, 2016

Member

wtf this stuff is not available in core?

@forki

forki Sep 3, 2016

Member

wtf this stuff is not available in core?

This comment has been minimized.

@matthid

matthid Sep 3, 2016

Member

...

@matthid

matthid Sep 3, 2016

Member

...

Show outdated Hide outdated src/Paket.Core/Cultures.fs
@@ -5,6 +5,7 @@ open System.Globalization
[<CompilationRepresentation (CompilationRepresentationFlags.ModuleSuffix)>]
module Cultures =
#if !DOTNETCORE

This comment has been minimized.

@forki

forki Sep 3, 2016

Member

can you please change it to #if DOTNETCORE and remove the not

@forki

forki Sep 3, 2016

Member

can you please change it to #if DOTNETCORE and remove the not

This comment has been minimized.

@matthid

matthid Sep 3, 2016

Member

done

@matthid
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

why is it running powershell? Do I need to be admin?

Member

forki commented Sep 4, 2016

why is it running powershell? Do I need to be admin?

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

Maybe try in another console window as well (I'm using ConEmu with Clink on windows 10 and its working well on cmd). Are you using powershell?

why is it running powershell? Do I need to be admin?

Because the dotnet sdk installer is written in powershell. No, admin shouldn't be required...

Member

matthid commented Sep 4, 2016

Maybe try in another console window as well (I'm using ConEmu with Clink on windows 10 and its working well on cmd). Are you using powershell?

why is it running powershell? Do I need to be admin?

Because the dotnet sdk installer is written in powershell. No, admin shouldn't be required...

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

"is written in Powershell" #sigh

Am 04.09.2016 18:12 schrieb "Matthias Dittrich" notifications@github.com:

Maybe try in another console window as well (I'm using ConEmu with Clink
on windows 10 and its working well on cmd). Are you using powershell?

why is it running powershell? Do I need to be admin?

Because the dotnet sdk installer is written in powershell. No admin
shouldn't be required...


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1785 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOK_Kkzuz3SEX2RexD1rlFxPAgHyks5qmu3ZgaJpZM4JDrgC
.

Member

forki commented Sep 4, 2016

"is written in Powershell" #sigh

Am 04.09.2016 18:12 schrieb "Matthias Dittrich" notifications@github.com:

Maybe try in another console window as well (I'm using ConEmu with Clink
on windows 10 and its working well on cmd). Are you using powershell?

why is it running powershell? Do I need to be admin?

Because the dotnet sdk installer is written in powershell. No admin
shouldn't be required...


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1785 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOK_Kkzuz3SEX2RexD1rlFxPAgHyks5qmu3ZgaJpZM4JDrgC
.

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

I guess now that powershell runs on unix they will remove the bash installer soon. It's so sad...

Member

matthid commented Sep 4, 2016

I guess now that powershell runs on unix they will remove the bash installer soon. It's so sad...

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

the issue is console2, it seems to work from good old command line window. headdesk

Member

forki commented Sep 4, 2016

the issue is console2, it seems to work from good old command line window. headdesk

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

So the installer itself is not working?

Member

matthid commented Sep 4, 2016

So the installer itself is not working?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

no but it goes a step further:

image

Member

forki commented Sep 4, 2016

no but it goes a step further:

image

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

There might be a way to workaround with redirection and stuff ...
The new error doesn't look good, maybe the install was corrupted. Can you try deleting the Microsoft/dotnet folder?

Member

matthid commented Sep 4, 2016

There might be a way to workaround with redirection and stuff ...
The new error doesn't look good, maybe the install was corrupted. Can you try deleting the Microsoft/dotnet folder?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

where exactly is this?

Member

forki commented Sep 4, 2016

where exactly is this?

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

Try to delete C:\Users\Steffen\AppData\Local\Microsoft\dotnet and try again.

Member

matthid commented Sep 4, 2016

Try to delete C:\Users\Steffen\AppData\Local\Microsoft\dotnet and try again.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

seems to work. now:

image

Member

forki commented Sep 4, 2016

seems to work. now:

image

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

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

Member

forki commented Sep 4, 2016

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

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

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?

Member

matthid commented Sep 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

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

Member

forki commented Sep 4, 2016

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

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

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

Member

matthid commented Sep 4, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

I just added it and now things work

Member

forki commented Sep 4, 2016

I just added it and now things work

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

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

Member

matthid commented Sep 4, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

that whole concept is nuts, but yes

Member

forki commented Sep 4, 2016

that whole concept is nuts, but yes

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

image

so now I have broken integration tests!?

Member

forki commented Sep 4, 2016

image

so now I have broken integration tests!?

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 4, 2016

Member

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

Member

matthid commented Sep 4, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 4, 2016

Member

ok will investigate tomorrow

Member

forki commented Sep 4, 2016

ok will investigate tomorrow

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

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

Collaborator

enricosada commented Sep 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 5, 2016

Member

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

Member

forki commented Sep 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 5, 2016

Member

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

Member

forki commented Sep 5, 2016

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

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

Collaborator

enricosada commented Sep 5, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 5, 2016

Member

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

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

Member

forki commented Sep 5, 2016

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

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

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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)

Collaborator

enricosada commented Sep 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 5, 2016

Member

otherwise is default fallback (no dependencies)

which would be wrong as well.

Member

forki commented Sep 5, 2016

otherwise is default fallback (no dependencies)

which would be wrong as well.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

Collaborator

enricosada commented Sep 5, 2016

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

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

Collaborator

enricosada commented Sep 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

enricosada commented Sep 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 5, 2016

Member

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

Member

matthid commented Sep 5, 2016

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

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 5, 2016

Member

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

Member

matthid commented Sep 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

@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

Collaborator

enricosada commented Sep 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

Collaborator

enricosada commented Sep 5, 2016

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

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 5, 2016

Collaborator

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

Collaborator

enricosada commented Sep 5, 2016

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 7, 2016

Member

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

Member

forki commented Sep 7, 2016

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

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Sep 7, 2016

Collaborator

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

Collaborator

enricosada commented Sep 7, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment