New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Standard support #77

Closed
teo-tsirpanis opened this Issue Jul 16, 2017 · 31 comments

Comments

Projects
None yet
7 participants
@teo-tsirpanis
Contributor

teo-tsirpanis commented Jul 16, 2017

No description provided.

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 7, 2018

I'd be willing to look into doing a multi-target build.

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 8, 2018

FSharp.Core 4.3.4 is not compatible with net40.
I think the only way to roll this project forward is to make a 2.0 release, multi-targeted to net45 and netstandard2.0.

That being the case, I think I will tackle a couple additional items in a 2.0 release:
Convert tests to Expecto
Use FSharp.Formatting beta for better documentation generation

I'm happy to entertain other suggestions.

@teo-tsirpanis

This comment has been minimized.

Contributor

teo-tsirpanis commented Apr 8, 2018

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 8, 2018

does anyone in the F# community really use .NET Standard 1.6? I'll add it...

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 8, 2018

...but if it came down to discovering any incompatibilities between 1.6 and 2.0, I would vote for restricting to 2.0 @teo-tsirpanis

@teo-tsirpanis

This comment has been minimized.

Contributor

teo-tsirpanis commented Apr 8, 2018

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 8, 2018

@teo-tsirpanis Adding netstandard1.6 generates lots of compile errors in the FSharpx.Collections project. I'm sticking to net45;netstandard2.0 for now. That combination of targets builds clean without any effort.. If anyone really wants to add netstandard1.6 they will have to submit a PR later.

@panesofglass

This comment has been minimized.

panesofglass commented Apr 8, 2018

Didn’t @enricosada already submit a PR for this?

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 8, 2018

@panesofglass by "this" you mean netstandard? I don't see it in the open PRs or any evidence in the git history.

@panesofglass

This comment has been minimized.

panesofglass commented Apr 9, 2018

@jackfoxy, @enricosada closed it recently after six months of no response on the PR. See #80.

@enricosada

This comment has been minimized.

enricosada commented Apr 10, 2018

I closed my PR because i want to send another, multitargeting netstandard2.0 and net45, because now all main editors support that (from VS 2017 15.6).

Unless real reason, for f# you shouldnt target netstandard1.6, just netstandard2.0.
The only real use of netstandard1.6 is that can be used by .net core 1.0, that that's unused now.

For F# doesnt matter netstandard1.6 anymore and cannot target lower version because fsharp.core.

You really want to use netstandard2.0 for .net core, because allow to not have lots of packages dependecines from NETStandard.Library (for 2.0 are not needed), and TONS more of bcl api to use

You can see in https://github.com/dotnet/standard/blob/master/docs/versions.md , that .net 4.6.1 support the netstandard2.0 already. the previous (net46) require .net standard1.3 (who cannot be done for f# anyway).

So netstandard2.0 + net4* is the way to go for libraries.

A NOTE While support just netstandard2.0 is ok for >= net461 , on net461 it require some automatically added dll (some shim). for net471 these are not required. There are a bit annoying.

So, if maintainer want:

  • support <= .net 4.6.1, it require a multitargeting (netstandard2.0 + net4*)
  • support >= .net 4.6.1, it can be done with just netstandard2.0 but i really reccomend to add a net461 target too, to make it easier to use.
  • support >= .net 4.7.1, just netstandard2.0 is ok

anyway, ignore netstandard1.6

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 10, 2018

I want to send another, multitargeting netstandard2.0 and net45

@enricosada looking forward to seeing this.

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 22, 2018

Moving 2.0 forward I have commited merged changes by @ChrSteinert and myself to https://github.com/fsprojects/FSharpx.Collections/tree/netstandard

Submit any relevant PRs to the netstandard branch.

2.0 issues:

  • Travis build problem
    #106
  • Fix "This construct is deprecated" warning from FSharpx.Collections.Tests
  • Migrate FSharpx.Collections.Tests to Expecto
  • Fix "This construct is deprecated" warning from FSharpx.Collections.Experimental.Tests
  • Fix Expecto FsCheck propery tests that throw
    #101
  • Expecto tests not comparing seq properly
    #98
  • Fix Expecto checks improperly converted that fail
  • Migrate FSharpx.Collections.Experimental.Tests to Expecto or get them running in NUnit
    #100
  • Eliminate need for binding redirects and remove app.config files
  • Could not load file or assembly 'nunit.framework' from some experimental tests:
  • nuget FSharp.Formatting prerelease
  • fix ...bin...dll was not found or is invalid from FSharp.Formatting
  • many FSharp.Formatting errors
    #102
  • finish up Expecto tests
    #104
  • update sourcelink
    #105
    https://libraries.io/nuget/SourceLink.Fake
  • breaking change: RequireQualifiedAccess
    #107
  • missing intellisense xml for several collections
  • add doc pages for all FSharpx.Collections
  • add Expecto BenchmarkDotNet test project and representative benchmarks
@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 24, 2018

@forki and/or @mausch please set up a branch for community PRs in moving the project forward to multitargeted and other enhancements, with the goal of a 2.0 release...
...or suggest another way to bring the project forward.

@forki

This comment has been minimized.

Member

forki commented Apr 25, 2018

I could add you as a maintener if you like

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 25, 2018

@forki OK

@forki

This comment has been minimized.

Member

forki commented Apr 26, 2018

good sent you team member request. you should be admin now.
As first step: please add yourself to maintainers list in readme.
what's your nuget.org name?

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 27, 2018

Nuget.org jackfoxy, thanks!

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented Apr 27, 2018

@ChrSteinert https://github.com/fsprojects/FSharpx.Collections/tree/netstandard set up as branch for developing 2.0.
See checklist a few messages up.

@forki

This comment has been minimized.

Member

forki commented Apr 27, 2018

This was referenced Apr 28, 2018

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 12, 2018

2.0 netstandard branch updated
all projects build
most Collections tests run, most of those pass
See #77 (comment) for project checklist
@ChrSteinert

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 13, 2018

netstandard branch progress report

see netstandard branch issues and checklist #77 (comment)

  • experimental tests build and Nunit attempts running, but fails

  • FSharp.Formatting on beta release, but many errors

  • Expecto tests problems comparing seqs and with most property tests

The right thing to do may still to be converting the Experimental tests from nunit to Expecto, but it is a lot of work and I could use some help.

@ChrSteinert

This comment has been minimized.

Contributor

ChrSteinert commented May 14, 2018

I already had some success with my RegEx Fu to convert some NUnit tests to Expecto. So a) there is progress, b) I think it makes sense to move over to Expecto.

@monkieboy

This comment has been minimized.

Contributor

monkieboy commented May 14, 2018

I think (if I am not missing something) that the Expect.equal can be changed to Expect.sequenceEqual to fix some of the Expecto tests. Would you like me to do that?

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 14, 2018

@monkieboy Certainly! And thanks for the Expecto tip.

@monkieboy

This comment has been minimized.

Contributor

monkieboy commented May 18, 2018

I pushed a few tests that worked locally, but the build failed in Travis. I am not sure if the build was failing before or not, where can I check, I haven't used Travis before?

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 18, 2018

@monkieboy Travis build is one of the things on the list to fix #77 (comment)
So don't worry about it, until you might want to work on that problem.

@monkieboy

This comment has been minimized.

Contributor

monkieboy commented May 18, 2018

@jackfoxy I think I fixed the build, if I make a pull request it wants to take the previous commit too, should I submit that and you can clear out the other pull request or will you prefer to accept and then I submit the PR just for the build fix? I am not 100% sure I have fixed it until travis runs it, maybe there is a better way to verify than simply running the build.sh on my macbook?

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 19, 2018

@monkieboy if you have test fixes and travis fix in separate commits of single PR, that is OK.

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 21, 2018

breaking change for 2.0:
#107

@jackfoxy jackfoxy referenced this issue May 26, 2018

Merged

Netstandard #108

@jackfoxy

This comment has been minimized.

Contributor

jackfoxy commented May 26, 2018

2.0 beta released
closing this issue

@jackfoxy jackfoxy closed this May 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment