Fable: Schritte zur Unterstützung von Projektdateien, die auf das vollständige .net-Framework ausgerichtet sind

Erstellt am 26. Mai 2017  ·  6Kommentare  ·  Quelle: fable-compiler/Fable

.NET Core ist cool und alles, aber der Einstieg in Fable erfordert eine steile Lernkurve und die Installation vieler Dinge (dotnet sdk, runtime). Ich bin mir sicher, dass viele Leute immer noch VS 2015 (oder 2013, 2010) verwenden und damit zufrieden sind.

Was sind die Herausforderungen, dies zu verwirklichen?

  • Parsen der alten Projektdatei (bereits in v0.7.x)
  • Paket verwenden (AFAIK, Paket funktioniert bereits mit der "alten" Projektdatei und VS 2015 unterstützt auch Paket)
  • Veröffentlichen Sie Fable.Tools als Nuget-Paket, wobei der Daemon eine Konsolen-App im Verzeichnis tools , das laut Nuget "der Pfad des Tools-Verzeichnisses zu PATH hinzugefügt wird"
question

Hilfreichster Kommentar

Es tut mir leid, aber ich kann dem keine Zeit widmen, wenn jemand daran interessiert ist, dass Fable 1.0 das alte Projektformat unterstützt, muss er selbst an diesem Feature arbeiten. Es ist bereits schwierig, Fable mit den aktuellen Tools zum Laufen zu bringen, und wir sind ein zu kleines Team, um zu viele Szenarien abzudecken. Im Moment ist VS für Windows der einzige Editor, der das neue .fsproj noch nicht unterstützt, und dies wird in Kürze der Fall sein. Ich denke nicht, dass es die Mühe wert ist, Entwicklungsressourcen zur Unterstützung des alten Formats bereitzustellen 😕

Parsen der alten Projektdatei (bereits in v0.7.x)

Bitte beachten Sie, dass dies nur mit Quelldateien und nicht bedingten Verweisen funktionierte, was die Benutzer dazu zwang, Verweise auf Bibliotheken manuell hinzuzufügen.

Paket verwenden

AFAIK, Paket mit dem alten Projekt funktioniert, indem viele bedingte Elemente in die .fsproj-Datei eingefügt werden, nicht mit der .fsproj.references Datei, die wir gerade verwenden. Wir müssten ganz anders mit Paket interagieren.

Fable.Tools als Nuget-Paket veröffentlichen, wobei der Daemon eine Konsolen-App im Tools-Verzeichnis ist

Ich habe das noch nie benutzt, daher bin ich mir nicht sicher, wie es funktionieren könnte.

Alle 6 Kommentare

Es tut mir leid, aber ich kann dem keine Zeit widmen, wenn jemand daran interessiert ist, dass Fable 1.0 das alte Projektformat unterstützt, muss er selbst an diesem Feature arbeiten. Es ist bereits schwierig, Fable mit den aktuellen Tools zum Laufen zu bringen, und wir sind ein zu kleines Team, um zu viele Szenarien abzudecken. Im Moment ist VS für Windows der einzige Editor, der das neue .fsproj noch nicht unterstützt, und dies wird in Kürze der Fall sein. Ich denke nicht, dass es die Mühe wert ist, Entwicklungsressourcen zur Unterstützung des alten Formats bereitzustellen 😕

Parsen der alten Projektdatei (bereits in v0.7.x)

Bitte beachten Sie, dass dies nur mit Quelldateien und nicht bedingten Verweisen funktionierte, was die Benutzer dazu zwang, Verweise auf Bibliotheken manuell hinzuzufügen.

Paket verwenden

AFAIK, Paket mit dem alten Projekt funktioniert, indem viele bedingte Elemente in die .fsproj-Datei eingefügt werden, nicht mit der .fsproj.references Datei, die wir gerade verwenden. Wir müssten ganz anders mit Paket interagieren.

Fable.Tools als Nuget-Paket veröffentlichen, wobei der Daemon eine Konsolen-App im Tools-Verzeichnis ist

Ich habe das noch nie benutzt, daher bin ich mir nicht sicher, wie es funktionieren könnte.

Ich glaube, ich habe hier das falsche "Problem" gemacht, das hätte eine Frage sein sollen :smile:

Ich hatte einige Gedanken über einen anderen Workflow und wollte es selbst ausprobieren, aber ich war mir nicht sicher, was benötigt wird, damit dies theoretisch funktioniert.

Ist es richtig, dass mit dotnet pack veröffentlichte Nuget-Pakete nicht in net45 verwendet werden können?

Ist es richtig, dass mit dotnet pack veröffentlichte Nuget-Pakete nicht in net45 verwendet werden können?

Nein, Sie können net45 als eines Ihrer Ziele ausrichten.

@ctaggart Schön, das ist gut zu wissen. Danke!

@ Zaid-Ajaj während new sdk (neues fsproj in Fable verwendet) in mono/msbuild.exe/dotnet cli gleich funktioniert (von fsharp.net.sdk >= 1.0.3 , wird in VS 2017 noch nicht unterstützt.
Sie können also net45 anvisieren (können mehrere Ziele im selben fsproj anvisieren, mit neuem SDK übrigens), aber es funktioniert sowieso nicht in VS. Ist nicht der .net-Kern das Problem, ist das neue SDK- und Projektformat.
Altes SDK hat viel mehr Probleme bei der plattformübergreifenden Unterstützung und ist ein Schmerz für die Maintaner (lesen Sie einfach die Projektinformationen, ist ein Schmerz und hat Probleme, wie @alfonsogarciacaro sagte)

In der VF#-Roadmap ist das erwartete Datum das Juli-Update, wenn VS 2017 das neue SDK in Visual F# unterstützt.

Anstatt also viel Arbeit zu tun, um alte SDKs zu unterstützen (Schmerz, zwei Implementierungen zu pflegen), die wirklich bald veraltet sind, ist es besser, ein bisschen zu warten (die plattformübergreifende Unterstützung von atm mit Fable und Editoren wie vscode/vsonmac ist großartig) bis Juli und verbessern Sie einfach das VS später mit net4* mit dem neuen SDK

Also irgendwann wird die msbuild .net Runtime (mono/vs/netcore) weniger wichtig sein (Danke an das neue SDK), wahrscheinlich wird sie für Benutzer transparent sein (sicher für Windows-Benutzer), aber atm ohne VS-Unterstützung ist nutzlos, um Zeit zu verbringen , weil Erfahrung (für Benutzer) aufpoliert und die Wartung (für Fable-Team) minimiert werden muss.
Neues SDK hilft, braucht aber mehr Zeit. Old sdk ist eine Zeitsenke, die in der .net-Welt sowieso veraltet ist.

@enricosada Der Hauptgrund, warum ich darüber nachgedacht habe, ist, die Einstiegserfahrung für Neulinge zu optimieren. Macht es den Leuten leicht, das zu verwenden, was sie jetzt haben (vs2015 oder niedriger), um mit Fable herumzuspielen. Ich verwende jetzt vs-Code mit Dotnet-Kern und das funktioniert gut. Aber das war nach einer Reihe von frustrierenden Versuchen, es überhaupt auf meinem Computer zum Laufen zu bringen. Ich konnte VS2017 nicht einmal auf meinem Computer installieren, was ein weiterer Grund ist, der mich dazu gebracht hat, darüber nachzudenken.

Nachdem ich Ihr Feedback gelesen habe, muss ich jedoch zustimmen, dass es besser ist, die Entwicklungsressourcen auf das neue SDK zu konzentrieren, und es lohnt sich, ein bisschen zu warten.

Nochmals vielen Dank für Ihre Zeit dafür.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen