The TPSDK supports development of TPs for quite antiquated F# tooling.
Going forward we should simplify our life for any future updates to the TPSDK (the current commits will be tagged for older development), e.g. I propose:
Assume TPs are developed using the standard template using .NET Core SDK 2.2+
Assume an F# host tool that is F# 4.5+, using FSharp.Core 4.5.2+ and netcoreapp2.2+ or net461+.
This corresponds to VS2017 later releases. We could be more aggressive here and say that if you want to deliver TPs for VS2017 you should pin to an specific legacy branch of the TPSDK which we no longer update
Assume reference assembly targets of (netstandard2.0+ or netcoreapp2.0+ or net461+) and FSharp.Core 4.5.2+
We could also move to assume VS2019-era tooling - I believe the main advantage would be assuming any host tooling is at least .NET Framework 4.7.2.
The TPSDK supports development of TPs for quite antiquated F# tooling.
Going forward we should simplify our life for any future updates to the TPSDK (the current commits will be tagged for older development), e.g. I propose:
Assume TPs are developed using the standard template using .NET Core SDK 2.2+
Assume an F# host tool that is F# 4.5+, using FSharp.Core 4.5.2+ and
netcoreapp2.2+ ornet461+.This corresponds to VS2017 later releases. We could be more aggressive here and say that if you want to deliver TPs for VS2017 you should pin to an specific legacy branch of the TPSDK which we no longer update
Assume reference assembly targets of (
netstandard2.0+ ornetcoreapp2.0+ ornet461+) andFSharp.Core 4.5.2+We could also move to assume VS2019-era tooling - I believe the main advantage would be assuming any host tooling is at least .NET Framework 4.7.2.