Fable: Что нужно сделать для поддержки файла проекта, ориентированного на полную структуру .NET?

Извините, но я не смогу посвятить этому какое-то время. Если кто-то заинтересован в Fable 1.0, поддерживающей старый формат проекта, им придется работать над этой функцией самостоятельно. Уже сейчас сложно заставить Fable работать с текущим набором инструментов, а наша команда слишком мала, чтобы охватить слишком много сценариев. На данный момент VS для Windows - единственный редактор, который еще не поддерживает новый .fsproj, и скоро он появится. Я не думаю, что выделение ресурсов на разработку для поддержки старого формата стоит затраченных усилий 😕

Разберите старый файл проекта (уже сделано в v0.7.x)

Обратите внимание, что это работало только с исходными файлами и безусловными ссылками, это заставляло пользователей вручную добавлять ссылки на библиотеки.

Использовать пакет

AFAIK, Paket со старым проектом работает, вставляя множество условных элементов в .fsproj, а не в файл .fsproj.references который мы используем прямо сейчас. Нам пришлось бы взаимодействовать с Пакетом совершенно по-другому.

Опубликуйте Fable.Tools как пакет nuget, где демон является консольным приложением в каталоге инструментов.

Я никогда не использовал это, поэтому я не уверен, как это могло бы работать.

Думаю, я сделал здесь неправильную "проблему", это должен был быть вопрос: smile:

У меня были некоторые мысли о другом рабочем процессе, и я хотел попробовать его самостоятельно, но не был уверен, что нужно для того, чтобы это работало теоретически.

Верно ли, что пакеты nuget, опубликованные с помощью dotnet pack не могут использоваться в net45?

Верно ли, что пакеты nuget, опубликованные с помощью пакета dotnet, не могут использоваться в net45?

Нет, вы можете настроить таргетинг на net45 качестве одной из своих целей.

@ctaggart Хорошо , это хорошо. Спасибо!

@ Zaid-Ajaj, в то время как новый sdk (новый fsproj, используемый в fable) работает так же в mono / msbuild.exe / dotnet cli (из fsharp.net.sdk> = 1.0.3 , еще не поддерживается в VS 2017.
Таким образом, вы можете настроить таргетинг на net45 (можно настроить таргетинг на несколько целей в одном и том же fsproj, с новым sdk btw), но это все равно не работает в VS. Проблема не в ядре .net, а в новом формате SDK и проекта.
Старый sdk - гораздо большая проблема в кроссплатформенной поддержке и является болью для специалистов по обслуживанию (просто прочитайте информацию о проекте, это проблема и есть проблемы, как сказал @alfonsogarciacaro )

В дорожной карте VF # ожидаемая дата - июльское обновление, когда VS 2017 будет поддерживать новый SDK в Visual F #.

Поэтому вместо того, чтобы делать много работы по поддержке старого sdk (боль для поддержки двух реализаций), который очень скоро устаревает, лучше ihmo немного подождать (банкомат поддержки кроссплатформенности с fable и редакторами, такими как vscode / vsonmac, потрясающий) до июля и просто улучшите VS с помощью net4* позже, используя новый sdk

Таким образом, в конечном итоге среда выполнения msbuild .net (mono / vs / netcore) будет иметь меньшее значение (спасибо новому sdk), вероятно, будет прозрачной для пользователей (наверняка для пользователей Windows), но атм без поддержки VS бесполезен, чтобы тратить время ihmo , потому что опыт (для пользователей) нужно отполировать, а обслуживание (для команды fable) нужно свести к минимуму.
Новый SDK поможет, но потребуется больше времени. Старый sdk - это приемник времени, который все равно устаревает в мире .net.

@enricosada Основная причина, по которой я думал об этом, - это упростить процесс начала работы для новичков. Упрощение для людей использования того, что у них есть сейчас (по сравнению с 2015 годом или ниже), для игры с баснями. Теперь я использую код vs с ядром dotnet, и он отлично работает. Но это было после серии разочаровывающих попыток заставить его работать в первую очередь на моей машине. Я даже не мог установить VS2017 на свой компьютер, что является еще одной причиной, по которой я задумался об этом.

Однако после прочтения ваших отзывов я должен согласиться с тем, что лучше сосредоточить ресурсы разработчиков на новом SDK и немного подождать.

Еще раз спасибо за то, что уделили этому время.