Fable: 完全な.netフレームワークを対象とするプロジェクトファイルをサポートする手順は?

作成日 2017年05月26日  ·  6コメント  ·  ソース: fable-compiler/Fable

.NET Coreはすばらしいものですが、Fableを使い始めるには、学習曲線を急いで、多くのもの(dotnet sdk、ランタイム)をインストールする必要があります。 多くの人がまだVS2015(または2013、2010)を使用していて、それに満足していると確信しています。

これを実現するための課題は何ですか?

  • 古いプロジェクトファイルを解析します(v0.7.xですでに実行されています)
  • paketを使用する(AFAIK、paketはすでに「古い」プロジェクトファイルで機能し、VS 2015はpaketもサポートしています)
  • Fable.Toolsをnugetパッケージとして公開します。デーモンはtoolsディレクトリのコンソールアプリであり、nugetによれば、「ツールディレクトリのパスはPATHに追加されます」
question

最も参考になるコメント

申し訳ありませんが、これに専念することはできません。古いプロジェクト形式をサポートするFable 1.0に興味がある場合は、その機能に自分で取り組む必要があります。 現在のツールセットでFableを機能させることはすでに困難であり、チームが小さすぎて多くのシナリオをカバーできません。 現在、VS for Windowsは、新しい.fsprojをまだサポートしていない唯一のエディターであり、まもなくサポートされる予定です。 古いフォーマットをサポートするために開発リソースを捧げる価値はないと思います😕

古いプロジェクトファイルを解析します(v0.7.xですでに実行されています)

これはソースファイルと無条件の参照でのみ機能することに注意してください。これにより、ユーザーはライブラリへの参照を手動で追加する必要がありました。

パケットを使用する

AFAIK、古いプロジェクトのPaketは、現在使用している.fsproj.referencesファイルではなく、.fsprojに多くの条件付きアイテムを挿入することで機能します。 まったく異なる方法でPaketとやり取りする必要があります。

Fable.Toolsをnugetパッケージとして公開します。デーモンはtoolsディレクトリのコンソールアプリです。

私はこれを使ったことがないので、どのように機能するのかわかりません。

全てのコメント6件

申し訳ありませんが、これに専念することはできません。古いプロジェクト形式をサポートするFable 1.0に興味がある場合は、その機能に自分で取り組む必要があります。 現在のツールセットでFableを機能させることはすでに困難であり、チームが小さすぎて多くのシナリオをカバーできません。 現在、VS for Windowsは、新しい.fsprojをまだサポートしていない唯一のエディターであり、まもなくサポートされる予定です。 古いフォーマットをサポートするために開発リソースを捧げる価値はないと思います😕

古いプロジェクトファイルを解析します(v0.7.xですでに実行されています)

これはソースファイルと無条件の参照でのみ機能することに注意してください。これにより、ユーザーはライブラリへの参照を手動で追加する必要がありました。

パケットを使用する

AFAIK、古いプロジェクトのPaketは、現在使用している.fsproj.referencesファイルではなく、.fsprojに多くの条件付きアイテムを挿入することで機能します。 まったく異なる方法でPaketとやり取りする必要があります。

Fable.Toolsをnugetパッケージとして公開します。デーモンはtoolsディレクトリのコンソールアプリです。

私はこれを使ったことがないので、どのように機能するのかわかりません。

私はここで間違った「問題」を作ったと思います、これは質問だったはずです:smile:

別のワークフローについて考えたことがあり、自分で試してみたかったのですが、理論的にはこれが機能するために何が必要かわかりませんでした。

dotnet pack公開されたnugetパッケージをnet45で使用できないのは正しいですか?

dotnet packで公開されたnugetパッケージをnet45で使用できないのは正しいですか?

いいえ、ターゲットの1つとしてnet45をターゲットにすることができます。

@ctaggartいいですね、それは知っておくと良いことです。 ありがとうございました!

@ Zaid-Ajaj(fableで使用される新しいfsproj)はmono / msbuild.exe / dotnet cli( VS2017ではまだサポートされていません。
したがって、 net45をターゲットにすることはできますが(新しいsdk btwを使用して、同じfsproj内の複数のターゲットをターゲットにすることができます)、とにかくVSでは機能しません。 問題は.netコアではなく、新しいSDKとプロジェクトの形式です。
古いSDKは、クロスプラットフォームのサポートでさらに多くの問題を抱えており、保守担当者にとっては苦痛です(

VF#ロードマップでは、VS2017がVisualF#で新しいSDKをサポートする7月の更新が予定されています。

したがって、すぐに廃止される古いSDK(2つの実装を維持するための苦痛)をサポートするために多くの作業を行う代わりに、7月まで少し待つ方が良いです(寓話とvscode / vsonmacのようなエディターを備えたクロスプラットフォームサポートATMは素晴らしいです)新しいSDKを使用して、後でnet4* VSを改善するだけです

したがって、最終的には、msbuild .netランタイム(mono / vs / netcore)はそれほど重要ではなく(新しいsdkに対してthx)、おそらくユーザーには透過的です(Windowsユーザーには確かに)が、VSサポートのないatmはihmoに時間を費やすのに役に立ちません、(ユーザー向けの)エクスペリエンスを磨き、(寓話チーム向けの)メンテナンスを最小限に抑える必要があるためです。
新しいSDKは役に立ちますが、もっと時間が必要です。 古いSDKはタイムシンクであり、.netの世界ではとにかく時代遅れになっています。

@enricosada私がこれを行うことを考えていた主な理由は、入門体験を合理化することです。 人々が現在持っているもの(vs2015以下)を使って寓話を簡単に試すことができるようにします。 私は現在dotnetcoreでvscodeを使用していますが、それは問題なく動作します。 しかし、これは、私のマシンで最初にそれを機能させるための一連のイライラした試みの後でした。 VS2017を自分のマシンにインストールすることすらできなかったので、これについて考えさせられました。

ただし、フィードバックを読んだ後、開発リソースを新しいSDKに集中させる方がよいので、少し待つだけの価値があることに同意する必要があります。

お時間をいただき、誠にありがとうございます。

このページは役に立ちましたか?
0 / 5 - 0 評価