Fable: dotnet SDK 2.0 preview 2 CLI est très lent ou se bloque

@ed-ilyin Une indication qu'il s'agit d'un problème de Fable ? Restaure-t-il d'autres projets "dotnet new" ok?

la restauration pour le nouveau projet f # classlib est très rapide

Je reçois le même problème avec le modèle simple, dotnet restore se bloque avec dotnet core 2 preview 2. Au début, je pensais que c'était la mauvaise version de paket car le programme d'amorçage n'était pas validé, mais le problème est toujours là avec la dernière version de paket.

Alors c'est lié à Paket ? Est-ce un problème connu? Ping @forki et @enricosada. Je pense qu'il y a de nombreux problèmes liés à F # résolus dans le SDK dotnet nocturne 2.0, mais je ne sais pas s'il y a quelque chose à ce sujet.

BTW, @ed-ilyin vous n'avez pas besoin d'appeler explicitement .paket/paket.exe restore , dotnet restore suffit. Mais je suppose que ce n'est pas lié au problème.

Que signifie pendre ? Pouvez-vous poster la sortie que vous voyez?

oui, et aussi dotnet --info s'il vous plaît

Bien sûr, il y a la capture d'écran avec les sorties dotnet --info et dotnet restore .

Et capture d'écran du moniteur d'activité :

Idem sur ma machine virtuelle Windows 10.

Donc, il ne donne aucune sortie dans la restauration de dotnet ?

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

Bien sûr, il y a la capture d'écran avec dotnet --info et dotnet restore
les sorties.
[image : capture d'écran 2017-07-05 alle 08 32 50]
https://user-images.githubusercontent.com/5064271/27850396-03968f02-615d-11e7-9f8f-bbf68e065330.png
Et capture d'écran du moniteur d'activité :
[image : capture d'écran 2017-07-05 alle 08 35 43]
https://user-images.githubusercontent.com/5064271/27850398-06aa0c14-615d-11e7-9e5f-39ad8e1f2d1b.png
Idem sur ma machine virtuelle Windows 10.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-313000889 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADgNOiU1A4lCiJYpkHIqSXXv7dNANFuks5sKyFhgaJpZM4OMj03
.

exactement, mais après environ 10 minutes ou plus, il commence à faire son travail

Pouvez-vous s'il vous plaît essayer d'exécuter "paket install" et réessayer d'exécuter la restauration de dotnet après cela ?

D'accord. Donc ça ne résout pas le problème. Pouvez-vous s'il vous plaît tout fermer. Et joindre ici ?

demo.zip

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

ne peut pas reproduire

@enricosada @davkean savez-vous si quelque chose n'allait pas dans dotnet SDK 2.0 preview 2 CLI ?

non, laissez-moi essayer localement aussi.

@rrelyea demande si vous pouviez déposer le problème avec repro contre NuGet/Home

Je ne comprends pas ce que cela signifie. Désolé, je suis noob.

@alfonsogarciacaro @enricosada est-ce une instance de https://github.com/fable-elmish/templates/issues/17 ?

Je suis revenu à l'aperçu1 - avec l'aperçu1, tout est à nouveau rapide

Revenir à l'aperçu 1 ne vous aidera pas très longtemps. :-)

Ce que j'aimerais, c'est une reproduction que je peux exécuter avec Preview 2.
Je ne pense pas avoir installé de modèles de fable.
Pouvez-vous me donner les étapes de reproduction complètes ?

@rrelyea @forki

Voici mes étapes de reproduction :

• dotnet new -i Fable.Template.Elmish.React
• dotnet nouvelle fable-elmish-react -n Repro1042
• cd Repro1042
• installation de fil ou de npm
• restauration dotnet <--- Prend> 10 minutes sur ma machine
• dotnet fable yarn-start <-- Prend également > 10 minutes sur ma 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

Remarque intéressante si vous exécutez la restauration dotnet avant d'exécuter le fil, c'est rapide. Une fois que le dossier node_modules est rempli, la restauration dotnet est lente. Cela semble lié à la découverte de @dsyme sur le nombre de fichiers dans le dossier du projet.

@rrelyea il y a des étapes dans le texte du problème :

Code de reproduction

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

@rrelyea donc ce n'est pas seulement un problème pour la restauration, mais aussi pour d'autres commandes dotnet.

Merci pour la confirmation @mike-morr ! Il semble donc que dotnet SDK 2 analyse tous les sous-répertoires à la recherche de fichiers .fsproj au lieu de l'actuel, comme le fait dotnet SDK 1, n'est-ce pas? Si c'est le cas, je peux penser à deux solutions :

• Ajoutez le fichier projet à la commande : dotnet restore MyProject.fsproj
• Déplacez le fichier de projet dans le dossier src comme indiqué ici : https://github.com/fable-elmish/templates/issues/17

Je suis un peu réticent à propos de la deuxième option car il n'est plus aussi simple d'exécuter des commandes Fable à partir de la racine, mais je suppose que nous devrons commencer à le faire de toute façon lorsque VS prendra en charge les nouveaux fichiers .fsproj et que nous devrons ajouter un fichier de solution aux modèles.

@alfonsogarciacaro nous pouvons être réticents, mais c'est la seule issue.

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

:

Merci pour la confirmation @mike-morr https://github.com/mike-morr ! Alors
il semble que dotnet SDK 2 analyse tous les sous-répertoires pour les fichiers .fsproj à la place
seul l'actuel comme dotnet SDK 1 le fait, n'est-ce pas ? Si c'est le
cas, je peux penser à deux solutions:

• Ajoutez le fichier projet à la commande : dotnet restore MyProject.fsproj
• Déplacez le fichier projet dans le dossier src comme indiqué ici :
  fable-elmish/templates#17
  https://github.com/fable-elmish/templates/issues/17

Je suis un peu réticent quant à la deuxième option car ce n'est pas si facile que ça
plus pour exécuter les commandes Fable à partir de la racine, mais je suppose que nous devrons commencer à le faire
que de toute façon lorsque VS prend en charge les nouveaux fichiers .fsproj et que nous devons ajouter un
fichier de solution aux modèles.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-313855119 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADgNMLHMWUoaeoYSu0Y9y3PR7l40-16ks5sL3_7gaJpZM4OMj03
.

@forki @alfonsogarciacaro Peut-être que nous ne devrions pas prendre en charge Preview 2. Ils vont devoir résoudre ce problème pour les projets MVC qui ont un dossier node_modules. Je crois comprendre que ce problème se reproduit également avec le modèle MVC prêt à l'emploi.

Ajouter de la complexité à ce projet pour contourner le problème qui, espérons-le, est temporaire semble une erreur.

Nous ne pouvons pas compter sur ce correctif. Personne de l'équipe dotnet n'a reconnu qu'il
est un bogue /cc @davkean

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

:

@forki https://github.com/forki @alfonsogarciacaro
https://github.com/alfonsogarciacaro Je pense que la bonne marche à suivre
est de ne pas prendre en charge l'aperçu 2. Ils vont devoir résoudre ce problème pour MVC
projets qui ont un dossier node_modules. Ma compréhension est que cela
émettre également des repros avec le modèle MVC prêt à l'emploi.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-313872338 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADgNDUaQl8BW-hpHYWpBLSS9e-z6UUKks5sL8ajgaJpZM4OMj03
.

Je suis d'accord avec le fait de le faire fonctionner hors de la boîte pour l'instant parce que nous ne pouvons pas prédire combien de temps cela sera corrigé

Les amis, le moyen le plus simple d'obtenir de l'aide sur un problème est de signaler un bogue à un référentiel Microsoft. Je n'ai pas assez de contexte pour comprendre où se trouve le bogue, mais commencez par http://github.com/dotnet/cli.

@davkean c'est la même chose que https://github.com/dotnet/core/issues/724 mais avec des repros différentes.

dans les problèmes liés, la cause première est analysée comme un engloutissement devenant malveillant dans la restauration et la construction. Solution : dotnet restore /p:EnableDefaultItems=false

Je pense que l'ajout de ce qui suit à un PropertyGroup dans le projet devrait contourner le problème :

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

@dsplaisted allez-vous corriger cela dans le sdk ?

@dsplaisted travaille toujours sur un correctif, mais oui, le correctif sera dans le SDK.

Cela devrait être corrigé avec ce MSBuild PR : https://github.com/Microsoft/msbuild/pull/2326

Le problème était que la fonctionnalité de métadonnées de lien automatique dans le SDK .NET utilisait un modèle qui provoquait une exécution O(n^2) (où n est le nombre d'éléments) lors de l'évaluation de MSBuild.

Merci beaucoup d'avoir résolu ce problème ! J'espère que ce n'était pas trop douloureux d'une solution
:)

Le 20 juillet 2017 à 16h16, "Daniel Plaisted" [email protected] a écrit :

Cela devrait être corrigé avec ce MSBuild PR : Microsoft/msbuild#2326
https://github.com/Microsoft/msbuild/pull/2326

Le problème était que les métadonnées de lien automatiques
La fonctionnalité https://github.com/dotnet/sdk/pull/1246 du SDK .NET a utilisé un
modèle qui a causé un temps d'exécution O(n^2) (où n est le nombre d'éléments)
lors de l'évaluation de MSBuild.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-316817507 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA3VvpbaU-Okpbh9Ksszxo9teJoDSfn7ks5sP7WDgaJpZM4OMj03
.

Je suis vraiment désolé si ce n'est pas le bon endroit pour en parler, mais je cherche juste à savoir si les modèles Fable .NET Core 2.0 Preview 2 sont corrects. Parce que lorsque j'essaie dotnet fable après la restauration, j'obtiens toujours :

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

L'installation du SDK 1.0.4 a résolu ce problème, mais le problème est que j'ai un autre problème avec le SDK 1.0.4 qui a été corrigé dans .NET Core 2... :( donc, en gros, je dois choisir le bogue que je veux subir pour l'instant. Et en installant les deux SDK pour choisir la souffrance à la volée en définissant le fichier global.json par projet, j'ai un troisième problème (qui ne semble pas être signalé), j'ai donc dû désinstaller complètement l'aperçu du SDK 2.0.

Quoi qu'il en soit, il y a un problème avec le modèle pour .NET Core SDK 2.0 ?

/cc @enricosada
Je suppose que vous devez vous débarrasser du sdk fsharp dans la première ligne du fsproj et du fichier deps et références. Enrico c'est bien ça ?

HMMMM, bon à savoir. Je vais tester, merci pour les conseils @forki. Je vais réinstaller le SDK .NET Core 2.0 pour vérifier.

Oui, avec le sdk 2, les bits f # sont entrés dans le sdk par défaut. Pas besoin de f# sdk
plus

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

HMMMM, bon à savoir. Je vais tester ça, merci pour le conseil @forki
https://github.com/forki . Je vais réinstaller le SDK .NET Core 2.0 pour vérifier
ce.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/fable-compiler/Fable/issues/1042#issuecomment-320497326 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AADgNPGIhUTG9-sOBrC4ogdOig3s2mSXks5sVY93gaJpZM4OMj03
.

J'ai réinstallé le SDK 2.0 preview 2 build 006497. Malheureusement, lors d'une nouvelle création de modèle pour Fable et après avoir supprimé toutes les références de Fsharp.NET.Sdk , je reçois toujours la même erreur... :/

@ryukinix Je ne pense pas qu'il s'agisse de FSharp.NET.Sdk car si je me souviens bien, ils voulaient rendre dotnet SDK 2.0 également compatible avec les projets utilisant ce package. Selon le message d'erreur, vous avez besoin du runtime netcore 1.0.4 pour exécuter Fable. AFAIK, il est possible d'installer un SDK et plusieurs runtimes, bien que je ne sois pas sûr du processus d'installation. Pouvez-vous essayer d'installer le SDK dotnet 2.0, puis d'installer [.0.4, mais uniquement le runtime .

BTW, je ne l'ai pas essayé, mais dans un autre problème (j'ai oublié lequel), un utilisateur a commenté les derniers bits du SDK 2.0 de dotnet (que vous pouvez télécharger à partir d' ici ) fonctionnaient bien.

@alfonsogarciacaro c'est drôle. Votre idée a un fort potentiel pour résoudre ce problème. Mais la façon dont j'ai corrigé était bizarre. En fait, en installant la version d'exécution jointe dans votre commentaire (1.0.4), j'ai reçu une nouvelle erreur :

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

Mais au lieu d'installer le runtime et de créer simplement un lien de symbole avec
sudo ln -s /opt/dotnet/shared/1.1.2 /opt/dotnet/shared/1.0.4 travaillé. La raison a fonctionné? Je n'ai aucune idée. Je m'attendais à ce que l'installation de la version 1.0.4 (qui est requise sur cette sortie) fonctionne...

Autre chose : si je n'ai jamais eu la version d'exécution 1.0.4 auparavant, pourquoi cela ne se produit-il pas avec le SDK 1.0.4 ? C'est bizarre.

Si j'exécute fable avec le runtime de .NET Core 1.1.2 et SDK 1.0.4, je n'ai aucun problème (comme je l'ai déjà dit, je n'ai pas de problèmes avec Fable mais j'en ai avec l'application console par exemple).

C'est vraiment drôle.

@ryukinix Ouais, encore beaucoup de pièces mobiles avec netcore, j'espère que la plupart d'entre elles seront résolues avec la sortie officielle de dotnet SDK 2.0 🙏

À propos de Fable fonctionnant avec dotnet SDK 1.0.4, c'est parce que cette version du SDK est livrée avec les runtimes 1.0.x et 1.1.x. Vous pouvez voir les runtimes installés dans le dossier shared où dotnet est installé ( /opt/dotnet dans votre cas). Je ne connais pas bien les règles de résolution pour les runtimes netcore, mais apparemment, cela a été corrigé grâce à votre lien symbolique.

Drôle en effet 😄

Je sais tout de même que ce fil n'est pas vraiment lié au problème que j'ai décrit, mais juste pour information complémentaire, l'installation du runtime 1.0.4 n'a pas fonctionné car cela :

Ce changement corrigeait le hack "toLower" dans le DependencyModel. Sur les machines sensibles à la casse, le SDK 2.0 sera rompu avec les frameworks partagés v1.0.0-1.0.4. Le bogue est corrigé dans la v1.0.5. Voir dotnet/core-setup#1559.

De toute évidence, Linux est une "machine sensible à la casse" (en fait, principalement tout ce qui n'est pas Windows)

Donc, cela a été corrigé dans les nouvelles versions et pour cette raison, le lien symbolique (bizarrement) pointant vers 1.1.2 fonctionne. Mais je ne comprends toujours pas pourquoi dotnet essaie de cibler l'ancienne version 1.0.4 uniquement sur le SDK 2.0 avec des runtimes partagés (j'utilise maintenant le SDK et le runtime officiels et ce bogue persiste si j'utilise 1.0.4).

Cela devrait être corrigé avec dotnet SDK 2 stable, n'hésitez pas à rouvrir s'il y a encore des problèmes.