Skip to content
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.

Sign up for GitHub

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

Jump to bottom

dotnet SDK 2.0 preview 2 CLI is very slow or hangs #1042

Closed
ed-ilyin opened this issue Jul 3, 2017 · 48 comments
Closed

dotnet SDK 2.0 preview 2 CLI is very slow or hangs #1042

ed-ilyin opened this issue Jul 3, 2017 · 48 comments

Comments

@ed-ilyin
Copy link

ed-ilyin commented Jul 3, 2017

Description

dotnet SDK 2.0 preview 2 CLI is very slow

Repro code

dotnet new -I Fable.Template
dotnet new fable -n Test3
cd Test3
.\.paket\paket.exe restore #or mono .\.paket\paket.exe restore on Mac
yarn install
dotnet restore

Expected and actual results

Expecting that dotnet resotre begin restore
Actually its hangs for long long time (on MacOs and on Windows)

Related information

  • Fable version (dotnet fable --version): this command hangs also
  • Operating system: macOS Sierra 10.12.5 and Microsoft Windows [Version 10.0.15063]
@ed-ilyin ed-ilyin mentioned this issue Jul 3, 2017
Closed
@dsyme
Copy link

dsyme commented Jul 3, 2017

@ed-ilyin Any indication this is a Fable issue? Does it restore other "dotnet new" projects ok?

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 3, 2017

restore for new f# classlib project is very fast

@Kurren123
Copy link
Contributor

Kurren123 commented Jul 4, 2017 •
edited
Loading

I am getting the same issue with the simple template, dotnet restore hangs with dotnet core 2 preview 2. At first I thought it was the wrong paket version because the bootstrapper wasn't commited, but the issue is still there with the latest version of paket.

@alfonsogarciacaro
Copy link
Member

So this is Paket related then? Is it a known problem? Pinging @forki and @enricosada. I think there are many F# related issues fixed in the nightly dotnet SDK 2.0 but I don't know if there's anything about this.

BTW, @ed-ilyin you don't need to call .paket/paket.exe restore explicitly, dotnet restore is enough. But I guess this is not related to the problem.

@forki
Copy link
Collaborator

forki commented Jul 4, 2017

What does hang mean? Can you post the output that you see?

@enricosada
Copy link
Contributor

yes, and also dotnet --info please

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 5, 2017

Sure, there is the screenshot with dotnet --info and dotnet restore outputs.
screen shot 2017-07-05 alle 08 32 50
And screenshot of activity monitor:
screen shot 2017-07-05 alle 08 35 43
Same in my Windows 10 virtual machine.

@forki
Copy link
Collaborator

forki commented Jul 5, 2017 via email

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 5, 2017 •
edited
Loading

exactly, but after some 10 minutes or more it starts do it's job

@forki
Copy link
Collaborator

forki commented Jul 5, 2017

Can you please try to run "paket install" and retry to run dotnet restore after that?

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 5, 2017

screen shot 2017-07-05 alle 09 17 41

@forki
Copy link
Collaborator

forki commented Jul 5, 2017

Ok. So it's doesn't fix it. Can you please zip everything up. And attach here?

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 5, 2017

demo.zip

@forki
Copy link
Collaborator

forki commented Jul 5, 2017 •
edited
Loading

PS D:\temp\fable> dotnet --version
2.1.0-preview1-006576

image

can't repro

@forki
Copy link
Collaborator

forki commented Jul 5, 2017

@enricosada @davkean do you know if something was wrong in dotnet SDK 2.0 preview 2 CLI?

@enricosada
Copy link
Contributor

nope, let me try locally too.

@forki forki mentioned this issue Jul 7, 2017
Closed
@forki
Copy link
Collaborator

forki commented Jul 7, 2017 •
edited
Loading

@rrelyea asks if you could please file the issue with repro against NuGet/Home

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 7, 2017

Can't understand what does this mean. Sorry, I'm noob.

@forki
Copy link
Collaborator

forki commented Jul 7, 2017

@alfonsogarciacaro @enricosada is this an instance of elmish/templates#17 ?

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 7, 2017 •
edited
Loading

I have rolled back to preview1 - with preview1 all again is fast

@rrelyea
Copy link

rrelyea commented Jul 7, 2017

Going back to preview 1 won't help you for very long. :-)

What I'd like is a repro that I can run with preview 2.
I don't think I have fable templates installed.
Can you give me full repro steps?

@mike-morr
Copy link
Member

mike-morr commented Jul 8, 2017 •
edited
Loading

@rrelyea @forki

Here are my Repro Steps:

  • dotnet new -i Fable.Template.Elmish.React
  • dotnet new fable-elmish-react -n Repro1042
  • cd Repro1042
  • yarn or npm install
  • dotnet restore <--- Takes > 10 minutes on my machine
  • dotnet fable yarn-start <-- Also takes > 10 minutes on my machine
.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
 Version:            2.0.0-preview2-006497
 Commit SHA-1 hash:  06a2093335

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25407-01
  Build    : 40c565230930ead58a50719c0ec799df77bddee9

@mike-morr
Copy link
Member

Interesting Note if you run dotnet restore before running yarn it's fast. Once the node_modules folder gets populated, dotnet restore is slow. This seems connected to @dsyme's discovery about the number of files in the project folder.

@ed-ilyin
Copy link
Author

ed-ilyin commented Jul 8, 2017 •
edited
Loading

@rrelyea there is steps in the issue text:

Repro code

dotnet new -I Fable.Template
dotnet new fable -n Test3
cd Test3
yarn install
dotnet restore

@forki
Copy link
Collaborator

forki commented Jul 8, 2017

@rrelyea so this is not only an issue for restore, but other dotnet commands as well.

@alfonsogarciacaro
Copy link
Member

Thanks for the confirmation @mike-morr! So it seems dotnet SDK 2 scans all subdirectories for .fsproj files instead only the current one as dotnet SDK 1 does, is that right? If that's the case I can think of two solutions:

I'm a bit reluctant about the second option because it's not that easy any more to run Fable commands from root, but I guess we'll have to start doing that anyway when VS supports the new .fsproj files and we have to add a solution file to the templates.

@forki
Copy link
Collaborator

forki commented Jul 8, 2017 via email

@mike-morr
Copy link
Member

mike-morr commented Jul 8, 2017 •
edited
Loading

@forki @alfonsogarciacaro Perhaps we should not support Preview 2. They are going to have to fix this for MVC projects which have node_modules folder. My understanding is that this issue repros with the out of the box MVC template as well.

Adding complexity to this project to workaround the issue that is hopefully temporary seems wrong.

@forki
Copy link
Collaborator

forki commented Jul 8, 2017 via email

@Kurren123
Copy link
Contributor

I agree with making it work out of the box for now because we can't predict how soon this will be fixed

@davkean
Copy link

davkean commented Jul 10, 2017

Folks, the easiest way to get traction on an issue is to file a bug against a Microsoft repo. I don't have enough context to understand where the bug is, but start with http://github.com/dotnet/cli.

@forki
Copy link
Collaborator

forki commented Jul 10, 2017

@davkean it's the same thing as dotnet/core#724 but with different repros.

@davkean davkean mentioned this issue Jul 10, 2017
Closed
@forki
Copy link
Collaborator

forki commented Jul 12, 2017

in the linked issues the root cause is analysed as gobbling going rogue in restore and build. Workaround: dotnet restore /p:EnableDefaultItems=false

@dsplaisted
Copy link

I think that adding the following to a PropertyGroup in the project should work around the issue:

<DefaultItemExcludes>$(DefaultItemExcludes);**\node_modules\**;node_modules\**</DefaultItemExcludes>

@forki
Copy link
Collaborator

forki commented Jul 19, 2017

@dsplaisted are you going to fix that in the sdk?

@davkean
Copy link

davkean commented Jul 19, 2017

@dsplaisted is still working on a fix, but yes the fix will be in the SDK.

@dsplaisted
Copy link

This should be fixed with this MSBuild PR: dotnet/msbuild#2326

The issue was that the automatic Link metadata feature in the .NET SDK used a pattern that caused an O(n^2) runtime (where n is the number of items) during MSBuild evaluation.

@StachuDotNet
Copy link

StachuDotNet commented Jul 20, 2017 via email

@emgarten emgarten mentioned this issue Jul 21, 2017
Closed
@ryukinix
Copy link

ryukinix commented Aug 6, 2017

I'm really sorry if this is the wrong place to talk about that, but I'm just looking around if the Fable .NET Core 2.0 preview 2 templates are correct . Because when I try dotnet fable after restore I always got:

     It was not possible to find any compatible framework version
         The specified framework 'Microsoft.NETCore.App', version '1.0.4' was not found.
           - Check application dependencies and target a framework version installed at:
               /
           - Alternatively, install the framework version '1.0.4'.

Installing SDK 1.0.4 solved this problem, but the problem is I have another problems with SDK 1.0.4 which was fixed into .NET Core 2... :( so basically I need to choose which bug i wants to suffer for now. And installing the both SDKs to choose the suffering on the fly setting the global.json file per project I have a third issue (which seems not be reported), so I did need to uninstall SDK 2.0 preview completely.

Anyway, there is some problem with the template for .NET Core SDK 2.0?

@forki
Copy link
Collaborator

forki commented Aug 6, 2017

/cc @enricosada
I ass you need to get rid of the fsharp sdk in the first line of the fsproj and from the deps and references file. Enrico is that correct?

@ryukinix
Copy link

ryukinix commented Aug 6, 2017 •
edited
Loading

HMMMM, good to know. I'll test it, thanks for the advice @forki. I'll reinstall the .NET Core SDK 2.0 to check.

@forki
Copy link
Collaborator

forki commented Aug 6, 2017 via email

@ryukinix
Copy link

ryukinix commented Aug 6, 2017 •
edited
Loading

I installed again the SDK 2.0 preview 2 build 006497. Unfortunately, on a new fresh template creation for Fable and after deleted all the references of Fsharp.NET.Sdk I'm still receiving the same error... :/

@alfonsogarciacaro
Copy link
Member

@ryukinix I don't think it's about the FSharp.NET.Sdk because if I recall correctly, they wanted to make dotnet SDK 2.0 also compatible with projects using this package. According to the error message you need the netcore 1.0.4 runtime to run Fable. AFAIK, it's possible to install one SDK and several runtimes, though I'm not sure about the installation process. Can you try installing the dotnet SDK 2.0 and then installing [.0.4, but only the runtime.

BTW, I haven't tried it but in another issue (I forgot which) a user commented dotnet SDK 2.0 latest bits (which you can download from here) were working fine.

@ryukinix
Copy link

ryukinix commented Aug 6, 2017 •
edited
Loading

@alfonsogarciacaro this is funny. Your idea has a strong potential to fix this. But the way I fixed was weird. Actually, installing the attached runtime version in your comment (1.0.4) I got a new error:

❯ dotnet -d fable
Telemetry is: Enabled
projectfactory: MSBUILD_EXE_PATH = /opt/dotnet/sdk/2.0.0-preview2-006497/MSBuild.dll
projectfactory: MSBuild project path = /home/lerax/Desktop/frontend/src/frontend.fsproj
projecttoolscommandresolver: resolving commandspec from 1 Tool Libraries.
projecttoolscommandresolver: Attempting to resolve command spec from tool dotnet-fable
projecttoolscommandresolver: nuget packages root:
- /home/lerax/.nuget/packages/
projecttoolscommandresolver: found tool lockfile at : /home/lerax/.nuget/packages/.tools/dotnet-fable/1.1.17/netcoreapp2.0/project.assets.json
projecttoolscommandresolver: expect deps.json at: /home/lerax/.nuget/packages/.tools/dotnet-fable/1.1.17/netcoreapp2.0/dotnet-fable.deps.json
projecttoolscommandresolver: attempting to create commandspec
packagedcommandspecfactory: attempting to find command dotnet-fable in dotnet-fable
PackagedCommandSpecFactory: Looking for prefercliruntime file at `/home/lerax/.nuget/packages/dotnet-fable/1.1.17/lib/netcoreapp1.0/../../prefercliruntime`
PackagedCommandSpecFactory: Ignoring prefercliruntime file as the tool target framework (1.0.4) has a different major version than the current CLI runtime (2.0.0-preview2-25407-01)
Running /opt/dotnet/dotnet exec --depsfile /home/lerax/.nuget/packages/.tools/dotnet-fable/1.1.17/netcoreapp2.0/dotnet-fable.deps.json --additionalprobingpath /home/lerax/.nuget/packages /home/lerax/.nuget/packages/dotnet-fable/1.1.17/lib/netcoreapp1.0/dotnet-fable.dll
Process ID: 8948
Error: assembly specified in the dependencies manifest was not found -- package: 'System.Diagnostics.DiagnosticSource', version: '4.3.0', path: 'lib/netstandard1.3/System.Diagnostics.DiagnosticSource.dll'

But instead installing the runtime and just create a symbol link with
sudo ln -s /opt/dotnet/shared/1.1.2 /opt/dotnet/shared/1.0.4 worked. The reason worked? I don't have clue. I expected that installing the version of 1.0.4 (which is required on that output) would works...

Another thing: If I never had the the 1.0.4 runtime version before, why this doesn't happens with the SDK 1.0.4? This is weird.

If I running fable with runtime of .NET Core 1.1.2 and SDK 1.0.4 I don't have any problem (as I say before, I don't have problems with Fable but I have with the console app at example).

This is really funny.

@alfonsogarciacaro
Copy link
Member

@ryukinix Yeah, still many moving pieces with netcore, hopefully most of them will be solved with the official release of dotnet SDK 2.0 🙏

About Fable working with dotnet SDK 1.0.4, that's because that SDK version comes bundled with runtimes 1.0.x and 1.1.x. You can see the runtimes installed in the shared folder where dotnet is installed (/opt/dotnet in your case). I don't know well the resolution rules for the netcore runtimes, but apparently it was fixed thanks to your symbol link.

Funny indeed 😄

@ryukinix
Copy link

ryukinix commented Aug 16, 2017 •
edited
Loading

I still know that this thread is not really related to the problem I described, but just for additional information, installing the runtime 1.0.4 not worked because that:

This change was correcting the "toLower" hack in the DependencyModel. On case-sensitive machines, the 2.0 SDK will be broken with shared frameworks v1.0.0-1.0.4. The bug is fixed in v1.0.5. See dotnet/core-setup#1559.

Obviously Linux is a "Case-sensitive machine" (btw, mostly anything that is not Windows)

So then, this was fixed in new versions and for this reason the symlink (weirdly) pointing to 1.1.2 works. But I still doesn't understand why dotnet try target the old version 1.0.4 only on SDK 2.0 with shared runtimes (I'm using the official SDK and runtime now and this bug persists if I use 1.0.4).

@amsterdamharu amsterdamharu mentioned this issue Aug 23, 2017
Closed
@alfonsogarciacaro
Copy link
Member

This should be fixed with dotnet SDK 2 stable, please feel free to reopen if there're still problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests