Fable: dotnet SDK 2.0 Preview 2 CLI ist sehr langsam oder hängt

@ed-ilyin Gibt es Hinweise darauf, dass dies ein Fable-Problem ist? Stellt es andere "dotnet new"-Projekte wieder her?

Die Wiederherstellung für ein neues f#-Classlib-Projekt ist sehr schnell

Ich bekomme das gleiche Problem mit der einfachen Vorlage, dotnet restore hängt mit dotnet Core 2 Preview 2. Zuerst dachte ich, es sei die falsche Paketversion, weil der Bootstrapper nicht festgeschrieben wurde, aber das Problem ist immer noch da die neueste Version des Pakets.

Das hängt also mit dem Paket zusammen? Ist es ein bekanntes Problem? Pingen Sie @forki und @enricosada. Ich denke, dass im nächtlichen dotnet SDK 2.0 viele F #-bezogene Probleme behoben wurden, aber ich weiß nicht, ob es etwas darüber gibt.

Übrigens, @ed-ilyin, Sie müssen .paket/paket.exe restore nicht explizit aufrufen, dotnet restore reicht aus. Ich vermute aber, dass dies nicht mit dem Problem zusammenhängt.

Was bedeutet hängen? Kannst du die Ausgabe posten, die du siehst?

Ja, und bitte auch dotnet --info

Sicher, da ist der Screenshot mit den Ausgaben dotnet --info und dotnet restore .

Und Screenshot des Aktivitätsmonitors:

Dasselbe in meiner virtuellen Windows 10-Maschine.

Es gibt also keine Ausgabe in der Dotnet-Wiederherstellung?

Am 05.07.2017 7:38 vorm. schrieb "Ed Ilyin" [email protected] :

Klar, da ist der Screenshot mit dotnet --info und dotnet restore
Ausgänge.
[Bild: Screenshot 2017-07-05 alle 08 32 50]
https://user-images.githubusercontent.com/5064271/27850396-03968f02-615d-11e7-9f8f-bbf68e065330.png
Und Screenshot des Aktivitätsmonitors:
[Bild: Screenshot 2017-07-05 alle 08 35 43]
https://user-images.githubusercontent.com/5064271/27850398-06aa0c14-615d-11e7-9e5f-39ad8e1f2d1b.png
Dasselbe in meiner virtuellen Windows 10-Maschine.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-313000889 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADgNOiU1A4lCiJYpkHIqSXXv7dNANFuks5sKyFhgaJpZM4OMj03
.

genau, aber nach ungefähr 10 Minuten oder mehr beginnt es, seine Arbeit zu tun

Können Sie bitte versuchen, "paket install" auszuführen und danach erneut versuchen, dotnet restore auszuführen?

OK. Es behebt es also nicht. Kannst du bitte alles verpacken. Und hier anhängen?

demo.zip

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

kann nicht reproduzieren

@enricosada @davkean wissen Sie, ob in dotnet SDK 2.0 Preview 2 CLI etwas nicht stimmte?

Nein, ich versuche es auch lokal.

@rrelyea fragt, ob Sie das Problem bitte mit Repro gegen NuGet/Home einreichen könnten

Kann nicht verstehen, was das bedeutet. Entschuldigung, ich bin Noob.

@alfonsogarciacaro @enricosada ist dies eine Instanz von https://github.com/fable-elmish/templates/issues/17 ?

Ich habe auf preview1 zurückgerollt - mit preview1 geht alles wieder schnell

Zurück zu Vorschau 1 wird Ihnen nicht lange helfen. :-)

Was ich möchte, ist eine Repro, die ich mit Vorschau 2 ausführen kann.
Ich glaube nicht, dass ich Fabelvorlagen installiert habe.
Können Sie mir vollständige Repro-Schritte geben?

@rrelyea @forki

Hier sind meine Repro-Schritte:

• dotnet new -i Fable.Template.Elmish.React
• dotnet new fable-elmish-react -n Repro1042
• CD Repro1042
• Garn oder npm installieren
• dotnet-Wiederherstellung <--- Dauert > 10 Minuten auf meinem Computer
• dotnet Fable Yarn-Start <-- Dauert auch > 10 Minuten auf meiner Maschine

.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

Interessanter Hinweis , wenn Sie dotnet restore ausführen, bevor Sie Garn ausführen, ist es schnell. Sobald der Ordner „node_modules“ gefüllt ist, ist die dotnet-Wiederherstellung langsam. Dies scheint mit der Entdeckung von @dsyme über die Anzahl der Dateien im Projektordner zusammenzuhängen.

@rrelyea es gibt Schritte im Problemtext:

Repro-Code

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

@rrelyea , das ist also nicht nur ein Problem für die Wiederherstellung, sondern auch für andere dotnet-Befehle.

Danke für die Bestätigung @mike-morr! Es scheint also, dass dotnet SDK 2 alle Unterverzeichnisse nach .fsproj-Dateien durchsucht, anstatt nur das aktuelle, wie es dotnet SDK 1 tut, ist das richtig? Wenn das der Fall ist, fallen mir zwei Lösungen ein:

• Fügen Sie die Projektdatei dem Befehl hinzu: dotnet restore MyProject.fsproj
• Verschieben Sie die Projektdatei wie hier beschrieben in den Ordner src : https://github.com/fable-elmish/templates/issues/17

Bei der zweiten Option bin ich etwas zurückhaltend, weil es nicht mehr so ​​einfach ist, Fable-Befehle von root aus auszuführen, aber ich denke, wir müssen sowieso damit beginnen, wenn VS die neuen .fsproj-Dateien unterstützt und wir eine hinzufügen müssen Lösungsdatei zu den Vorlagen.

@alfonsogarciacaro Wir können zögern, aber es ist der einzige Ausweg.

Am 08.07.2017 15:11 schrieb "Alfonso Garcia-Caro" < [email protected]

:

Danke für die Bestätigung @mike-morr https://github.com/mike-morr ! Damit
es scheint, dass dotnet SDK 2 stattdessen alle Unterverzeichnisse nach .fsproj-Dateien durchsucht
nur das aktuelle als dotnet SDK 1, ist das richtig? Wenn das der ist
Fall fallen mir zwei Lösungen ein:

• Fügen Sie die Projektdatei dem Befehl hinzu: dotnet restore MyProject.fsproj
• Verschieben Sie die Projektdatei wie hier beschrieben in den src-Ordner:
  fabel-elmish/templates#17
  https://github.com/fable-elmish/templates/issues/17

Bei der zweiten Option bin ich etwas zurückhaltend, weil es nicht so einfach ist
mehr, um Fable-Befehle von root aus auszuführen, aber ich denke, wir müssen damit anfangen
das sowieso, wenn VS die neuen .fsproj-Dateien unterstützt und wir eine hinzufügen müssen
Lösungsdatei zu den Vorlagen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-313855119 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADgNMLHMWUoaeoYSu0Y9y3PR7l40-16ks5sL3_7gaJpZM4OMj03
.

@forki @alfonsogarciacaro Vielleicht sollten wir Vorschau 2 nicht unterstützen. Sie müssen dies für MVC-Projekte beheben, die den Ordner node_modules haben. Mein Verständnis ist, dass dieses Problem auch mit der sofort einsatzbereiten MVC-Vorlage reproduziert wird.

Das Hinzufügen von Komplexität zu diesem Projekt, um das Problem zu umgehen, das hoffentlich vorübergehend ist, scheint falsch zu sein.

Darauf können wir uns nicht verlassen. Niemand vom dotnet-Team hat dies bestätigt
ist ein Fehler /cc @davkean

Am 08.07.2017 8:12 nachm. schrieb "Mike Morrison" < [email protected]

:

@forki https://github.com/forki @alfonsogarciacaro
https://github.com/alfonsogarciacaro Ich denke, die richtige Vorgehensweise
soll Vorschau 2 nicht unterstützen. Sie müssen dies für MVC beheben
Projekte, die den Ordner node_modules haben. Mein Verständnis ist, dass dies
Geben Sie Repros auch mit der sofort einsatzbereiten MVC-Vorlage aus.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-313872338 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADgNDUaQl8BW-hpHYWpBLSS9e-z6UUKks5sL8ajgaJpZM4OMj03
.

Ich stimme zu, dass es vorerst sofort einsatzbereit ist, da wir nicht vorhersagen können, wie schnell dies behoben wird

Leute, der einfachste Weg, ein Problem zu lösen, besteht darin, einen Fehler in einem Microsoft-Repo einzureichen. Ich habe nicht genug Kontext, um zu verstehen, wo der Fehler liegt, aber beginnen Sie mit http://github.com/dotnet/cli.

@davkean es ist dasselbe wie https://github.com/dotnet/core/issues/724 , aber mit unterschiedlichen Repros.

In den verknüpften Problemen wird die Hauptursache als verschlingender Schurken beim Wiederherstellen und Erstellen analysiert. Problemumgehung: dotnet restore /p:EnableDefaultItems=false

Ich denke, dass das Hinzufügen des Folgenden zu einem PropertyGroup im Projekt das Problem umgehen sollte:

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

@dsplaisted wirst du das im SDK beheben?

@dsplaisted arbeitet noch an einem Fix, aber ja, der Fix wird im SDK sein.

Dies sollte mit diesem MSBuild PR behoben werden: https://github.com/Microsoft/msbuild/pull/2326

Das Problem bestand darin, dass die Funktion zum automatischen Verknüpfen von Metadaten im .NET SDK ein Muster verwendete, das während der MSBuild-Evaluierung eine O(n^2)-Laufzeit (wobei n die Anzahl der Elemente ist) verursachte.

Vielen Dank für die Lösung! Hoffentlich war die Reparatur nicht zu schmerzhaft
:)

Am 20. Juli 2017 um 16:16 Uhr schrieb „Daniel Plaisted“ [email protected] :

Dies sollte mit dieser MSBuild PR behoben werden: Microsoft/msbuild#2326
https://github.com/Microsoft/msbuild/pull/2326

Das Problem war, dass die automatischen Link-Metadaten
https://github.com/dotnet/sdk/pull/1246 Funktion im .NET SDK verwendet a
Muster, das eine Laufzeit von O(n^2) verursacht hat (wobei n die Anzahl der Elemente ist)
während der MSBuild-Evaluierung.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-316817507 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA3VvpbaU-Okpbh9Ksszxo9teJoDSfn7ks5sP7WDgaJpZM4OMj03
.

Es tut mir wirklich leid, wenn dies der falsche Ort ist, um darüber zu sprechen, aber ich schaue mich nur um, ob die Fable .NET Core 2.0 Preview 2-Vorlagen korrekt sind. Denn wenn ich nach der Wiederherstellung dotnet fable versuche, bekomme ich immer:

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

Die Installation von SDK 1.0.4 löste dieses Problem, aber das Problem ist, dass ich andere Probleme mit SDK 1.0.4 habe, das in .NET Core 2 behoben wurde ... :( also muss ich im Grunde wählen, unter welchem ​​​​Bug ich jetzt leiden möchte. Und beim Installieren der beiden SDKs, um das Leiden im laufenden Betrieb auszuwählen, das die global.json-Datei pro Projekt einstellt, habe ich ein drittes Problem (das anscheinend nicht gemeldet wird), also musste ich die SDK 2.0-Vorschau vollständig deinstallieren.

Wie auch immer, es gibt ein Problem mit der Vorlage für .NET Core SDK 2.0?

/cc @enricosada
Ich bin der Meinung, dass Sie das fsharp sdk in der ersten Zeile des fsproj und aus der deps- und Referenzdatei entfernen müssen. Enrico ist das richtig?

HMMMM, gut zu wissen. Ich werde es testen, danke für den Rat @forki. Ich werde das .NET Core SDK 2.0 zur Überprüfung neu installieren.

Ja, mit SDK 2 gingen die f#-Bits in das Standard-SDK. Kein f#-SDK erforderlich
mehr

Am 06.08.2017 12:03 schrieb "Manoel Vilela" [email protected] :

HMMMM, gut zu wissen. Ich werde das testen, danke für den Rat @forki
https://github.com/forki . Ich werde das .NET Core SDK 2.0 zur Überprüfung neu installieren
das.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-320497326 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADgNPGIhUTG9-sOBrC4ogdOig3s2mSXks5sVY93gaJpZM4OMj03
.

Ich habe das SDK 2.0 Preview 2 Build 006497 erneut installiert. Leider erhalte ich bei einer neuen, frischen Vorlagenerstellung für Fable und nachdem alle Referenzen von Fsharp.NET.Sdk gelöscht wurden, immer noch denselben Fehler ... :/

@ryukinix Ich glaube nicht, dass es um das FSharp.NET.Sdk geht, denn wenn ich mich richtig erinnere, wollten sie dotnet SDK 2.0 auch mit Projekten kompatibel machen, die dieses Paket verwenden. Laut Fehlermeldung benötigen Sie die netcore 1.0.4 Runtime , um Fable auszuführen. AFAIK, es ist möglich, ein SDK und mehrere Laufzeiten zu installieren, obwohl ich mir über den Installationsprozess nicht sicher bin. Können Sie versuchen, das dotnet SDK 2.0 zu installieren und dann [.0.4, aber nur die Runtime .

Übrigens, ich habe es nicht ausprobiert, aber in einem anderen Problem (ich habe vergessen, welches) kommentierte ein Benutzer, dass die neuesten Bits von dotnet SDK 2.0 (die Sie von hier herunterladen können) gut funktionierten.

@alfonsogarciacaro das ist lustig. Ihre Idee hat ein starkes Potenzial, dies zu beheben. Aber die Art und Weise, wie ich reparierte, war seltsam. Tatsächlich habe ich beim Installieren der angehängten Laufzeitversion in Ihrem Kommentar (1.0.4) einen neuen Fehler erhalten:

❯ 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'

Aber installieren Sie stattdessen die Laufzeitumgebung und erstellen Sie einfach einen Symbollink mit
sudo ln -s /opt/dotnet/shared/1.1.2 /opt/dotnet/shared/1.0.4 hat funktioniert. Der Grund hat funktioniert? Ich habe keine Ahnung. Ich hatte erwartet, dass die Installation der Version 1.0.4 (die für diese Ausgabe erforderlich ist) funktionieren würde ...

Noch etwas: Wenn ich noch nie die Laufzeitversion 1.0.4 hatte, warum passiert das nicht mit dem SDK 1.0.4? Das ist seltsam.

Wenn ich Fable mit der Laufzeit von .NET Core 1.1.2 und SDK 1.0.4 ausführe, habe ich kein Problem (wie ich bereits sagte, habe ich keine Probleme mit Fable, aber ich habe beispielsweise mit der Konsolen-App).

Das ist wirklich lustig.

@ryukinix Ja, immer noch viele bewegliche Teile mit Netcore, hoffentlich werden die meisten davon mit der offiziellen Veröffentlichung von dotnet SDK 2.0 gelöst 🙏

Über die Arbeit von Fable mit dotnet SDK 1.0.4 liegt das daran, dass diese SDK-Version mit den Laufzeiten 1.0.x und 1.1.x gebündelt geliefert wird. Sie können die installierten Runtimes im Ordner shared sehen, in dem dotnet installiert ist (in Ihrem Fall /opt/dotnet ). Ich kenne die Auflösungsregeln für die Netcore-Laufzeiten nicht gut, aber anscheinend wurde es dank Ihres Symbollinks behoben.

Wirklich lustig 😄

Ich weiß immer noch, dass dieser Thread nicht wirklich mit dem von mir beschriebenen Problem zusammenhängt, aber nur als zusätzliche Information, die Installation der Laufzeitumgebung 1.0.4 hat nicht funktioniert, weil das :

Diese Änderung korrigierte den „toLower“-Hack im DependencyModel. Auf Computern, bei denen die Groß-/Kleinschreibung beachtet wird, wird das 2.0 SDK mit gemeinsam genutzten Frameworks v1.0.0-1.0.4 beschädigt. Der Fehler ist in v1.0.5 behoben. Siehe dotnet/core-setup#1559.

Offensichtlich ist Linux eine "Case-Sensitiv-Maschine" (übrigens meistens alles, was nicht Windows ist)

Dies wurde dann in neuen Versionen behoben und aus diesem Grund funktioniert der Symlink (seltsamerweise), der auf 1.1.2 zeigt. Aber ich verstehe immer noch nicht, warum dotnet versucht, die alte Version 1.0.4 nur auf SDK 2.0 mit gemeinsam genutzten Laufzeiten auszurichten (ich verwende jetzt das offizielle SDK und die offizielle Laufzeit und dieser Fehler bleibt bestehen, wenn ich 1.0.4 verwende).

Dies sollte mit dotnet SDK 2 stable behoben werden, bitte zögern Sie nicht, es erneut zu öffnen, wenn es weiterhin Probleme gibt.