Support .NET Platform Standard 1.6 (inc. .NET Core 1.0)

[khellang]

I figured it's time to start this discussion 😄

Here are some threads for reference:

castleproject/Core#90
nsubstitute/NSubstitute#192
devlooped/moq#168

There's a PR pending for .NET Core support in Castle.Core at castleproject/Core#92

[adamralph]

As soon as Castle.Core support the dotnet TFN I'm happy to do this.

[jeremymeng]

Would it be okay to start the work based on https://github.com/castleproject/Core/tree/netcore? Most of the big changes are already in. I am willing to give it a first stab.

[adamralph]

@jeremymeng I think would be fine to grab some custom binary to reference for now, so long as your are prepared to rebase/squash your commits back to something clean (or have someone else do that) when Castle for netcore (or whatever other name is goes by) is on NuGet.

[jchannon]

Where are we at with this?

[thecodejunkie]

We have a green build against rc2 now (including tests, i.e all tests that do not require FakeItEasy) NancyFx/Nancy#2418 and would be happy to help transfer knowledge on rc2 changes to help this move along

[blairconrad]

Hey, @jchannon and @thecodejunkie. As you can see, @jeremymeng had kindly been doing some work on this for us, but the core team had all been focusing on FIE 2.0, which I think we're nearly ready to release the second (and final, one hopes) RC for.

We'd be grateful for any insight you have to offer, but I'm not going to be available for the next two weeks, so can't personally do anything. I'll leave it up to @thomaslevesque and @adamralph to coordinate with you.

[jeremymeng]

@jchannon @thecodejunkie

There are a couple of work items now

• Replacement of binary serialization used in FileStorage. So far I haven't had success in using a Json or Xml serializer.

  Update I've change how the serialization is done. Instead of serializing MethodInfo, now fully-qualified type name, method name, and argument types are serialized. In Deserialization, the MethodInfo instance is retrieved again from the type.

• Seemly incorrect usage of my custom AssemblyLoadContext. It seems that loading from a file would fail due to missing dependencies.

• Move to RC2

• integration into build system, etc.

  Update Now it just builds fine using rake when the .NET Core VS tooling is installed.

• The test BinarySerializationHelper does binary serialization and serialization for arbitrary types. I'm inclining to not support it on .NET Core.

Any helps are welcome 😄

[thomaslevesque]

@jeremymeng, thanks for all your work on this task!

Any helps are welcome 😄

Right now I'm focusing on FakeItEasy 2.0.0-rc2, but once it's released, I'll be glad to give you a hand. I know almost nothing about .NET Core, though...

[adamralph]

Given the recent sweeping changes and volatile nature of .NET Core, I'm not sure it's worth investing any time in this in the near future. I'm leaning towards closing for now, and opening a new issue to support the relevant .NET Standard after RTM.

We appreciate the efforts of @jeremymeng and he is, of course, welcome to carry on with his work on #617 but right now, if we have no intention of supporting .NET core until some later release, I believe this issue is just noise in our backlog.

[thomaslevesque]

@adamralph, RC2 is scheduled to be released about now (mid-May), and RTM is scheduled for the end of June. Sounds like "near future" to me 😉. This issue is still relevant, so I think we should keep it open.

[adamralph]

OK, np. Let's leave it open.

[henningst]

RTM shipped as planned on June 27th. Do you have any ETA on adding .NET Core support? Moq has published an alpha supporting .NET Core.

[blairconrad]

Thanks for the interest, @henningst. We don't have an ETA as such (given that we all work on FakeItEasy if and when we have spare time to so, it's hard to guess at dates), but rest assured that we do want to support .NET Core. The same chap (@jeremymeng) that's been working on adding .NET support to Castle.Core (which, like Moq, has alphas that currently support the prerelease .NET Core) has been making great strides in helping FakeItEasy support .NET Core. As we're able we'll look at how best to integrate his work.

[jeremymeng]

People who are interested can download private nupkgs here https://ci.appveyor.com/project/jeremymeng/fakeiteasy/build/artifacts

official pre-release builds on AppVeyor: https://ci.appveyor.com/nuget/FakeItEasy

[adamralph]

Thanks @jeremymeng.

@henningst if you like, you can use @jeremymeng's app veyor build as your "alpha" channel for now.

[henningst]

Thanks for the tip! I'll give that a try :)

[adamralph]

How are we affected by the recent revelation that netstandard 1.5 and 1.6 are going to be broken by 2.0?

[khellang]

I'm not sure the breaking change is real after all; https://twitter.com/terrajobst/status/786993233913978880

[adamralph]

Thanks @khellang, I missed that. Good to know!

[adamralph]

Assigned to 3.0.0 milestone.

[adamralph]

I checked off the integration tests item in The List.

Only specs to go! That's a good incentive to sort out xbehave once and for all.

BTW - I'd be content to push an 3.0 alpha to nuget.org now if we want to unblock NancyFx/Nancy#2612 and then push the first beta once we've got the specs running.

[thomaslevesque]

I'd be content to push an 3.0 alpha to nuget.org now if we want to unblock NancyFx/Nancy#2612 and then push the first beta once we've got the specs running.

Sounds like a good plan 👍

[blairconrad]

Oh, bother. I'd made a beta001. Can make an alpha001.

[adamralph]

FYI I just pushed xbehave 2.2.0 beta 1 to NuGet, with support for .NET Standard 1.0! https://www.nuget.org/packages/Xbehave/2.2.0-beta0001-build680

[blairconrad]

I'll expect your "hook up the specs" PR when I wake up!

[thomaslevesque]

I'll expect your "hook up the specs" PR when I wake up!

I'm working on making the specs work on netcoreapp1.0 now. I haven't done much for .NET Core support so far, so I guess it's my last chance 😉

[blairconrad]

Haha! I was just having some fun.

Also, welcome to Heck.

[adamralph]

The project.json for the test project in xbehave itself might be a good reference. The explicit use of the testutility package should be ignored though, that's for the meta level code which allows scenarios to test scenarios.

…

On 28 Nov 2016 22:42, "Blair Conrad" ***@***.***> wrote: Haha! I was just having some fun. Also, welcome to heck. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#531 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApXSDs1VFenuwkFp85WGKF_jnFmlm3Zks5rC0q0gaJpZM4Fyobx> .

[thomaslevesque]

Also, welcome to Heck.

Well, the worst part is the poor VS integration. No Intellisense, no test runner and no debug for netstd 😒

The project.json for the test project in xbehave itself might be a good reference. The explicit use of the testutility package should be ignored though, that's for the meta level code which allows scenarios to test scenarios.

Thanks; actually, I copied and edited the project.json from integration tests, and it's working fine. I just have one failing scenario to fix.

[adamralph]

The VS test runner should work. It works for the xbehave solution. On 28 Nov 2016 11:13 p.m., "Thomas Levesque" <notifications@github.com> wrote: Also, welcome to Heck. Well, the worst part is the poor VS integration. No Intellisense, no test runner and no debug for netstd 😒 The project.json for the test project in xbehave itself might be a good reference. The explicit use of the testutility package should be ignored though, that's for the meta level code which allows scenarios to test scenarios. Thanks; actually, I copied and edited the project.json from integration tests, and it's working fine. I just have one failing scenario to fix. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#531 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApXSNWN1QNyL3s3tYezaYEP_2L5h-IUks5rC1HvgaJpZM4Fyobx> .

[thomaslevesque]

The VS test runner should work. It works for the xbehave solution.

For me it doesn't see any test, not even the net40 ones. Maybe I need to install something else.

[adamralph]

The List is complete!

Fantastic work all round.

[blairconrad]

Huzzah! Well done, everyone!

[adamralph]

[blairconrad]

This issue has been released in FakeItEasy 3.0.0:
https://github.com/FakeItEasy/FakeItEasy/releases/3.0.0

@jeremymeng, @jonorossi, thanks for all your help.
Look for your names in the release notes! 🏆

[weitzhandler]

Can you please add support for modern Xamarin PCLs (Profile 44), that target only UWP, Droid and iOS?

[blairconrad]

@weitzhandler, thanks for your interest in FakeItEasy. I'll be the first to admit that I don't understand all the PCLs and whatnot, but I don't think we'll do this.
For starters, FakeItEasy relies on Castle.Core, which would have to support the profile, and it supports only .NETFramework 3.5, .NETFramework 4.0, .NETFramework 4.5, and .NETStandard 1.3. Also, I think the PCLs are the wave of the past, and we're looking forward to the .NET Standard.

My understanding is that the usual course would be to build an app's business logic into a PCL such that supports your target platform as well as .NET 4.0 or 4.5 or similar and then to have the test assemblies target that .NET Framework (or a compatible one). Profile44 supports .NET 4.5.1, so this should be an option for you.