-
Notifications
You must be signed in to change notification settings - Fork 26
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
NetStandard 2.0 support #136
Conversation
@alex-bogomaz some notes: use .net core sdk 2.0.0 (RTM)dont use dotnet target .net standard 2.0, not 1.6.and no need to target .net standard 1.6. go directly to use a sln fileas a note. if you want to can create a
etc. so you can restore/build it at once
this is also nicely supported in VSCODE 😄 and make easy to switch netcore/net refresh template of testis a good idea to refresh the templates of tests. you do in a temp dir:
to generate an new move test project in distinct directoriesthe project name can be the same. |
Just want to put forth that I'm really grateful for someone tackling this. I'm very much looking forward to a NETStandard build of this library - keep it coming! 🎉 |
Pull request is available, so what's holding back the release? |
Hey all - thanks for effort on this and sorry for slow response. I'll move towards getting this into master and released in the next few days. My current thinking is that we'll do a major version bump here (Unquote 4.x) and drop support for .NET 4.0 and PCL 256 profiles. |
@alex-bogomaz FYI I created an Unquote issue for the failing tests you discovered: #137 (thanks much for reporting the problem). |
@@ -62,6 +62,39 @@ module Internal = | |||
#if PORTABLE | |||
outputReducedExprsMsg outputGenericTestFailedMsg | |||
#else | |||
#if NETSTANDARD2_0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alex-bogomaz is there are reason for limiting the set of supported frameworks for NetStandard 2.0 here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only reason was NetStandard support for each particular framework:
- NUnit 3, Xunit 2 and Expecto - they support NetStandard 1.6.
- Fuchu, Xunit 1, MBUnit - not
- FSI - according to official MS announcements - it is not supported for NetCore yet: https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net-core-roadmap-update/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alex-bogomaz thanks, that makes sense. But I wonder if it matters that Fuchu, Xunit 1, MBUnit, and FSI don't support NetStandard since we are loading assemblies dynamically... I forget why we had to limit the PCL build to only the generic test failed function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephen-swensen Fuchu
is replaced by Expecto
afaik.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point. maybe we should not limit.
i'll test following scenario and get back with results:
- use dot net sdk 2.0
- create unit-test project, target net framework 461
- reference netstandard 2.0 unquote
- reference full-framework Fuchu
@enricosada @alex-bogomaz question: are there any practical downsides to targeting NetStandard 2.0 instead of NetStandard 1.6? i.e. will we be limiting the platform reach of our NetStandard build? According to https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-platforms-support
|
If this is OK - we can target Standard 1.6. Btw - i still need to check if we should limit number of supported testing frameworks for Netstandard... |
@alex-bogomaz I think it is fine not to have custom exception serialization if that is the only limitation and NetStandard 1.6 opens up wider platform support. The request for supporting serialization in custom exceptions goes back to 2012: #98 ... I imagine it is a fairly niche use-case: "It is required for them to pass AppDomain boundaries". |
Just ignore net standard1.6, target only 2.0
The 2.0 is the only one who matter.
The 1.6 doesn't add more (not obsolete) net profiles
To justify it, and tooling isn't there for it.
The new lts is soon the 2.0
From mobile
…--
Enrico Sada
@enricosada
________________________________
From: Stephen Swensen <notifications@github.com>
Sent: Wednesday, November 1, 2017 9:12:45 PM
To: SwensenSoftware/unquote
Cc: Enrico Sada; Mention
Subject: Re: [SwensenSoftware/unquote] NetStandard 2.0 support (#136)
@alex-bogomaz<https://github.com/alex-bogomaz> I think it is fine not to have custom exception serialization if that is the only limitation and NetStandard 1.6 opens up wider platform support. The request for supporting serialization in custom exceptions goes back to 2012: #98<#98> ... I imagine it is a fairly niche use-case: "It is required for them to pass AppDomain boundaries".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#136 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAI_K5VagbMQkLbqTPBkbT3s0yYwTmlaks5syNC9gaJpZM4PwL-g>.
|
hi, so we are keeping NetStandard 2.0 - right? |
@alex-bogomaz yeah sounds like that's the way to go |
Closing this pull request: I merged the changes to master from command line. Prepping for release now. Thanks @alex-bogomaz and @enricosada for contributing this work! |
Now things around NetCore and NetStandard tooling are stabilized
and we can give a new life to @enricosada 's PR #126.
This PR should resolve #130. Please review.
Building
To build Netstandard 1.6 Unquote you need to have NetCore SDK 2.0:
Now
build.bat
also buildsUnquote.NetStandard\Unquote.NetStandard.fsproj
project andmerges NetStandard 1.6 dll into existing NuGet package.
Tests
To run NetCore tests execute following:
Few notes:
CustomExceptionSerializationTests.fs
tests are excluded:because of limited serialization support in NetStandard 1.6.
The question here - should we have support of NetStandard 2.0 for Unquote and what are use-cases for such exception serialization?
Not sure why this operation is not failing under NetCore.
DecompilationTests
are failing:with errors like:
but this is not something NetCore-related, but rather difference between F#4.0 and 4.1.
There are exactly same exceptions when compiling Unquote using VS 2017. In VS 2015 those 2 tests are green.
I've asked the question here: dotnet/fsharp#3698
but still have trouble understanding how to fix this issue in Unquote.
Testing frameworks support.
Assertions.fs
includes Unquote NetStandard 1.6 support for Expecto, Xunit2 and NUnit3frameworks.
To test support execute following: