Join GitHub today
Update projects to .NET sdk, support `netstandard2.0`, drop tfms, etc #38
create a modern package, use .net sdk, cleanup infra, add ci.
add support for
drop support for discontinued
drop support for
drop support for
upgrade form FSharp.NET.Sdk style (deprecated in .NET Core Sdk 1.0) to .NET Sdk fsproj
cleanup shared props and fsproj, using conventions of .NET Sdk:
remove old VS11 projects, new projects works in VS
…rget framework remove compiler define and code for `PCL_FPARSEC` the compiler defines `PCL` is not used anymore. The code is not yet removed because it's a big change, but because the compiler define is not set, the code is unused
I'd like to not enter the discussion about strong naming here, because is always really long. Just to be clear, for me is a big no.
What matter is that the fparsec net45 is strong signed, that's ok and must continue to be like that (it's out of scope for this PR).
I checked the built assemblies and are strong signed
@stephan-tolksdorf as a note, i tried in https://github.com/enricosada/fparsec/tree/split_prop to split the LowTrust in multiple fsproj (so FParsec.fsproj and
So @stephan-tolksdorf for me this PR is ready
Frankly I'm surprised that there is strong opinion not to sign. Not once I had to build myself (Deedle, Math.NET, R.NET, older Dapper), and wonder if there is a single person out there who had to rebuild a signed assembly as non-signed because signed is unusable. What inconvenience one line in a project file could cause? You are forcing to multitarget when classic framework signed final consumer is involved. But with practice forking+repacking becomes not so difficult. Much easier than such discussions.…
On Thu, Feb 28, 2019, 1:55 AM Phillip Carter ***@***.***> wrote: Any discussion about strong naming should involve Paket vs. NuGet, Tabs vs. Spaces, and Vim vs. Emacs
@enricosada Thanks again for your work on this PR! I'm going to review it this weekend so that we can merge it.
I'm curious, why did you switch to conditionals based on TargetFramework from TargetFrameworkIdentifier in 63f5049 (after deleting the fallback initialization of TargetFrameworkIdentifier in 5231fbd)?
I think that's why I originally set the
Do you still want to add the SourceLink support?
Great work @enricosada! I think this PR is ready to be merged.
I've made some minor adjustments. Let me know if you find any of them objectionable.
If you think the PR is ready, please squash the PR, give it a descriptive commit message and then rebase merge it with master. (I've invited you as a GitHub contributor.)
Thank you so much for your contribution!