Fable: Étapes pour prendre en charge le fichier de projet ciblant le framework .net complet ?

Je suis désolé mais je ne pourrai pas y consacrer de temps, si quelqu'un est intéressé par Fable 1.0 prenant en charge l'ancien format de projet, il devra travailler sur cette fonctionnalité lui-même. Il est déjà difficile de faire fonctionner Fable avec l'ensemble d'outils actuel et nous sommes une trop petite équipe pour couvrir trop de scénarios. À l'heure actuelle, VS pour Windows est le seul éditeur qui n'a pas encore pris en charge le nouveau .fsproj, et il le sera bientôt. Je ne pense pas que dédier des ressources de développement pour prendre en charge l'ancien format en vaille la peine 😕

Analyser l'ancien fichier de projet (déjà fait dans la v0.7.x)

Veuillez noter que cela ne fonctionnait qu'avec les fichiers source et les références

Utiliser le paquet

AFAIK, Paket avec l'ancien projet fonctionne en injectant beaucoup d'éléments conditionnels dans le .fsproj, pas avec le fichier .fsproj.references que nous utilisons actuellement. Nous aurions à interagir avec Paket d'une manière complètement différente.

Publiez Fable.Tools en tant que package nuget où le démon est une application de console dans le répertoire d'outils

Je ne l'ai jamais utilisé donc je ne sais pas comment cela pourrait fonctionner.

Je pense que j'ai fait le mauvais "problème" ici, cela aurait dû être une question :sourire:

J'avais pensé à un flux de travail différent et je voulais l'essayer par moi-même, mais je n'étais pas sûr de ce qui était nécessaire pour que cela fonctionne en théorie.

Est-il correct que les packages nuget publiés avec dotnet pack ne puissent pas être utilisés dans net45 ?

Est-il correct que les packages nuget publiés avec dotnet pack ne puissent pas être utilisés dans net45 ?

Non, vous pouvez cibler net45 comme l'une de vos cibles.

@ctaggart Nice, c'est bon à savoir. Merci!

@Zaid-Ajaj tandis que le nouveau sdk (nouveau fsproj utilisé dans fable) fonctionne de la même manière dans mono/msbuild.exe/dotnet cli (de fsharp.net.sdk >= 1.0.3 , n'est pas encore pris en charge dans VS 2017.
Vous pouvez donc cibler net45 (peut cibler plusieurs cibles dans le même fsproj, avec le nouveau sdk btw), mais cela ne fonctionne pas dans VS de toute façon. Ce n'est pas le noyau .net, le problème, c'est le nouveau format de SDK et de projet.
L'ancien sdk pose beaucoup plus de problèmes de support multiplateforme et est pénible pour les maintaners (il suffit de lire les informations sur le projet est une douleur et a des problèmes, comme l' a dit

Dans la feuille de route VF#, la date prévue est la mise à jour de juillet, lorsque VS 2017 prendra en charge le nouveau SDK dans Visual F#.

Donc, au lieu de faire beaucoup de travail pour supporter l'ancien sdk (douleur pour maintenir deux implémentations) qui devient obsolète très bientôt, il vaut mieux que ihmo attende un peu (le support multiplateforme atm avec fable et des éditeurs comme vscode/vsonmac est génial) jusqu'en juillet et améliorez simplement le VS avec net4* plus tard, en utilisant le nouveau sdk

Donc finalement le runtime msbuild .net (mono/vs/netcore) aura moins d'importance (merci au nouveau sdk), sera probablement transparent pour les utilisateurs (bien sûr pour les utilisateurs de Windows), mais l'atm sans support VS, est inutile de passer du temps ihmo , car l'expérience (pour les utilisateurs) doit être peaufinée et la maintenance (pour l'équipe fable) doit être minimisée.
Le nouveau SDK vous aidera, mais nécessite plus de temps. L'ancien sdk est un puits de temps, qui devient de toute façon obsolète dans le monde .net.

@enricosada La principale raison pour laquelle j'envisageais de le faire était de rationaliser l'expérience de démarrage pour les nouveaux arrivants. Permettre aux gens d'utiliser facilement ce qu'ils ont maintenant (vs2015 ou inférieur) pour jouer avec la fable. J'utilise vs code maintenant avec dotnet core et cela fonctionne bien. Mais c'était après une série d'essais frustrants pour le faire fonctionner en premier lieu sur ma machine. Je ne pouvais même pas installer VS2017 sur ma machine, ce qui est une autre raison qui m'a fait penser à cela.

Cependant, après avoir lu vos commentaires, je suis d'accord pour dire que concentrer les ressources de développement sur le nouveau SDK est mieux et qu'attendre un peu en vaudra la peine.

Merci encore pour votre temps à ce sujet.