Fable: Passos para dar suporte a arquivos de projeto visando a estrutura completa .net?

Sinto muito, mas não poderei dedicar nenhum tempo a isso, se alguém estiver interessado no Fable 1.0 suportando o formato de projeto antigo, eles terão que trabalhar nesse recurso por conta própria. Já é difícil fazer o Fable funcionar com o conjunto atual de ferramentas e somos uma equipe muito pequena para cobrir muitos cenários. No momento, o VS para Windows é o único editor que ainda não oferece suporte ao novo .fsproj, e o fará em breve. Não acho que a dedicação de recursos de desenvolvimento para suportar o formato antigo valha o esforço 😕

Analise o arquivo de projeto antigo (já feito na v0.7.x)

Observe que isso só funcionou com arquivos de origem e referências não condicionais , o que forçou os usuários a adicionar referências manualmente às bibliotecas.

Use Paket

AFAIK, Paket com o projeto antigo funciona injetando muitos itens condicionais no .fsproj, não com o arquivo .fsproj.references que estamos usando agora. Teríamos que interagir com o Paket de uma forma completamente diferente.

Publique Fable.Tools como um pacote nuget, onde o daemon é um aplicativo de console no diretório de ferramentas

Eu nunca usei isso, então não tenho certeza de como poderia funcionar.

Acho que fiz o "problema" errado aqui, deveria ser uma pergunta: sorria:

Eu pensei sobre um fluxo de trabalho diferente e queria tentar sozinho, mas não tinha certeza do que é necessário para que isso funcione em teoria.

É correto que os pacotes nuget publicados com dotnet pack não podem ser usados ​​no net45?

É correto que os pacotes nuget publicados com o pacote dotnet não podem ser usados ​​no net45?

Não, você pode segmentar net45 como um de seus destinos.

@ctaggart Bom, é bom saber. Obrigada!

@ Zaid-Ajaj enquanto new sdk (novo fsproj usado na fábula) funciona da mesma forma em mono / msbuild.exe / dotnet cli (de fsharp.net.sdk> = 1.0.3 , ainda não é compatível com o VS 2017.
Portanto, você pode direcionar net45 (pode direcionar múltiplos destinos no mesmo fsproj, com o novo sdk btw), mas não funciona no VS de qualquer maneira. Não é o núcleo .net, o problema, é o novo formato de SDK e projeto.
O SDK antigo tem muito mais problemas no suporte de plataforma cruzada e é uma dor para os mantenedores (ler as informações do projeto é uma dor e tem problemas, como @alfonsogarciacaro disse)

No roteiro do VF #, a data esperada é a atualização de julho, quando o VS 2017 oferecerá suporte ao novo SDK no Visual F #.

Então, em vez de trabalhar muito para dar suporte ao sdk antigo (dor de manter duas implementações) que está ficando obsoleto muito em breve, é melhor ihmo esperar um pouco (o suporte de plataforma cruzada atm com fábula e editores como vscode / vsonmac é incrível) até julho e apenas melhore o VS com net4* mais tarde, usando o novo SDK

Então, eventualmente, o tempo de execução do msbuild .net (mono / vs / netcore) importará menos (thx para o novo sdk), provavelmente será transparente para os usuários (com certeza para usuários do Windows), mas atm sem suporte ao VS, é inútil gastar tempo ihmo , porque a experiência (para os usuários) precisa ser aprimorada e a manutenção (para a equipe de fábulas) precisa ser minimizada.
O novo SDK ajuda, mas precisa de mais tempo. O SDK antigo é um desperdício de tempo, que está ficando obsoleto de qualquer maneira no mundo .net.

@enricosada A principal razão de eu estar pensando em fazer isso é agilizar a experiência de introdução para os iniciantes. Tornando mais fácil para as pessoas usarem o que têm agora (vs2015 ou anterior) para brincar com fábulas. Estou usando o código vs agora com o núcleo dotnet e isso funciona bem. Mas isso foi depois de uma série de tentativas frustrantes de fazê-lo funcionar na minha máquina. Não consegui nem instalar o VS2017 na minha máquina, outra razão que me fez pensar nisso.

No entanto, depois de ler seu feedback, tenho que concordar que focar os recursos de desenvolvimento no novo SDK é melhor e esperar um pouco valerá a pena.

Obrigado novamente pelo seu tempo nisso.