Support .NET Framework

[kkm000]

Yes, a deliberate pun on the #7's title :)

I am wondering why support for the framework had to go with the commits de52172 and 69fd979. FParsec itself still targets as low as net40 (I think F# 4.1 may generate code only for net45 and above, though). It also seems that these changes did not require any APIs beyond 1.6, if I am not mistaken, so 2.0 seems too high for a library.

One of these commits did away with the README.md and LICENSE files by the way. It's not clear if that was intentional.

[rspeele]

Warning: bitterness follows. This is not your fault. You seem to be a nice person!

No reason. If I did something in the course of attempting to support .NET Standard, and it doesn't make sense to you, it's almost certain the answer is "I didn't know what I was doing". If it's any consolation, there have been no improvements from 0.4.0 to 1.0.0 so if you have a .NET framework project, using 0.4.0 does not hurt you at all.

I went through a rampage back in July trying to get all my libraries compatible with .NET Standard as fast as possible so I could ultimately do the same for Rezoom.SQL. I think at the time I figured .NET Standard 2.0 would be a simple way to go across the board and would work for FParsec-Pipes, LicenseToCIL, Rezoom, and Rezoom.SQL. This consumed an otherwise nice evening, helped absolutely nobody and, since I didn't manage to make the type provider work on .NET Core and gave up, it actually broke Rezoom.SQL for anyone who updates its dependencies to the max version. I should've released the .NET standard versions of FParsec-Pipes and LicenseToCIL as RC or beta versions, but, in my immense hubris, did not.

There is a chance that I could enjoy coding new features on any of these projects, but it will not happen because the cloud of attempting and failing to support .NET standard casts a wide shadow of shame on all of them. Arguably that is my fault for not putting enough effort into the attempt. But it's unappealing to use my copious free time just keeping up with a treadmill of tooling changes when the code remains exactly the same. What's remarkable is how using a new technology can be fun but applying it to code you've filed away as "done" is about as far from fun as you can get.

In conclusion if I was going to do something to rectify this, it would be to release a v2.0.0 going right back to .NET Framework only and just pretend core/standard do not exist. I think this would work well for my own other libraries that depend on each other, but I don't know if other users would be screwed over. One possible user of the .NET Standard version would be GraphQL-net by my friend @ckimes89 but I don't think he has updated to it anyway.

[kkm000]

Oh, I do feel for you! This whole .NET Core business felt like a beta or an RC all the way through (DNX? project.json? Back to MSBuild?). Fortunately, they seem to have settled on something working in the long term at last. F# support also lagged behind C#/VB.

Arguably that is my fault for not putting enough effort into the attempt.

Not at all, don't blame yourself! This whole thing was a rollercoaster. I hope is "was", not "has been"--at the least, it has slowed down.

This consumed an otherwise nice evening

If I could count mine! :(

Let me see if I can make a concise multitargeting PR.

[kkm000]

BTW, the lazy me finally figured out the DisableImplicitFSharpCoreReference and why my internal packages were targeting an FSharp.Core version higher than I specified. So this was quite a helpful digression! http://msbuildlog.com/ is da tool!