Fable: ¿Pasos para admitir archivos de proyecto dirigidos al marco .net completo?

Lo siento, pero no podré dedicar tiempo a esto, si alguien está interesado en que Fable 1.0 admita el formato de proyecto anterior, tendrá que trabajar en esa función ellos mismos. Ya es difícil hacer que Fable funcione con el conjunto de herramientas actual y somos un equipo demasiado pequeño para cubrir demasiados escenarios. En este momento, VS para Windows es el único editor que aún no es compatible con el nuevo .fsproj, y pronto lo hará. No creo que valga la pena dedicar recursos de desarrollo para respaldar el formato anterior 😕

Analizar el archivo de proyecto antiguo (ya hecho en v0.7.x)

Tenga en cuenta que esto solo funcionó con archivos de origen y referencias no condicionales , esto obligó a los usuarios a agregar manualmente referencias a las bibliotecas.

Usar Paket

AFAIK, Paket con el proyecto antiguo funciona inyectando muchos elementos condicionales en el .fsproj, no con el archivo .fsproj.references que estamos usando en este momento. Tendríamos que interactuar con Paket de una manera completamente diferente.

Publique Fable.Tools como un paquete nuget donde el demonio es una aplicación de consola en el directorio de herramientas

Nunca he usado esto, así que no estoy seguro de cómo podría funcionar.

Creo que hice el "problema" incorrecto aquí, esta debería haber sido una pregunta: sonríe:

Pensé un poco en un flujo de trabajo diferente y quería probarlo por mi cuenta, pero no estaba seguro de lo que se necesita para que esto funcione en teoría.

¿Es correcto que los paquetes nuget publicados con dotnet pack no se puedan usar en net45?

¿Es correcto que los paquetes nuget publicados con dotnet pack no se puedan usar en net45?

No, puede apuntar a net45 como uno de sus objetivos.

@ctaggart Niza, es bueno saberlo. ¡Gracias!

@ Zaid-Ajaj mientras que el nuevo sdk (nuevo fsproj usado en fable) funciona igual en mono / msbuild.exe / dotnet cli (de fsharp.net.sdk> = 1.0.3 , aún no es compatible con VS 2017.
Por lo tanto, puede apuntar a net45 (puede apuntar a varios objetivos en el mismo fsproj, con un nuevo sdk por cierto), pero de todos modos no funciona en VS. No es el núcleo .net, el problema es el nuevo sdk y el formato del proyecto.
El viejo SDK es un problema mucho mayor en el soporte multiplataforma y es un dolor para los mantenedores (solo leer la información del proyecto es un problema y tiene problemas, como dijo @alfonsogarciacaro )

En la hoja de ruta de VF #, la fecha esperada es la actualización de julio, cuando VS 2017 admitirá el nuevo sdk en Visual F #.

Entonces, en lugar de trabajar mucho para admitir el viejo sdk (dolor para mantener dos implementaciones) que se está volviendo obsoleto muy pronto, es mejor que ihmo espere un poco (el cajero automático de soporte cruzado con fábula y editores como vscode / vsonmac es increíble) hasta julio y simplemente mejore el VS con net4* más tarde, usando el nuevo sdk

Entonces, eventualmente, el tiempo de ejecución de msbuild .net (mono / vs / netcore) importará menos (gracias al nuevo sdk), probablemente será transparente para los usuarios (seguro para los usuarios de Windows), pero cajero automático sin soporte VS, es inútil pasar tiempo ihmo , porque la experiencia (para los usuarios) debe pulirse y el mantenimiento (para el equipo de fábulas) debe minimizarse.
El nuevo sdk ayudará, pero necesitará más tiempo. El SDK antiguo es un sumidero de tiempo, que de todos modos se está volviendo obsoleto en el mundo .net.

@enricosada La principal razón por la que estaba pensando en hacer esto es para optimizar la experiencia de inicio para los recién llegados. Facilitando a las personas el uso de lo que tienen ahora (vs2015 o anterior) para jugar con la fábula. Estoy usando vs code ahora con dotnet core y eso funciona bien. Pero esto fue después de una serie de intentos frustrantes para que funcionara en primer lugar en mi máquina. Ni siquiera pude instalar VS2017 en mi máquina, que es otra razón que me hizo pensar en esto.

Sin embargo, después de leer sus comentarios, estoy de acuerdo en que enfocar los recursos de desarrollo en el nuevo sdk es mejor y esperar un poco valdrá la pena.

Gracias de nuevo por tu tiempo en esto.