Support .net core (and asp.net core)

[fleed]

Is .net core supported? It would also be nice to be able to configure feature toggles using the new conventions and mechanisms defined by asp.net core.

[jason-roberts]

Hi @fleed .net core support is coming...

[jason-roberts]

Also asp.net core 1.0

[calloncampbell]

Any update on this?

[jason-roberts]

Hi @calloncampbell - should be implemented by end of year - I'm just deciding exactly what next release will incorporate and whether we'll need to move to v4 to follow semver if there's any breaking changes

[Assassyn]

Right now you can wait for VS 2017 as it changes the way dotnet cli and dotnet core works.

[jason-roberts]

@SzymonSasin I'm also thinking about whether to wait for netstandard 2...

[Assassyn]

@jason-roberts vs 2017 RC is still far from ns2.0.

I am getting my head around netstandard and slowly I am starting to think that you should use the lowest possible version as the coverage of other .NET flavours will be larger. I mean that if the api for netstandsrd 1.1 is enought for the FeatureToggle there culd be one nugget for win 8, .net 4.5 and dotnet core, which should make deployment easier.

[mehalick]

I too would love .NET Core support but would hate to wait until VS 2017, especially since the dev IDE isn't relevant to the assemblies that we'd get via NuGet. Sure you might have to migrate a solution from VS 2015 to 2017 at some point but by the time 2017 RTMs I'd expect that process to be simple and automatic.

Regarding .NET Standard, I agree with @SzymonSasin, unless there are APIs you need in 2.0 you should target a lower version to increase the amount of platform support you'd get. If you look at https://docs.microsoft.com/en-us/dotnet/articles/standard/library it's probably a choice between 1.2 and 1.6.

[jason-roberts]

Decided to start porting work at .Net Standard v1.4 and work from there...

[jason-roberts]

@mehalick @fleed @calloncampbell @Assassyn Hi all - just put a pre-release version on NuGet with .NET Core support - would be great if you could test out the NuGet packages and some of the toggle types in some different app types/platforms :)

https://www.nuget.org/packages/FeatureToggle/4.0.0-rc1

https://github.com/jason-roberts/FeatureToggle/blob/master/Release-Notes.md

[steventmayer]

@jason-roberts I'm going to be playing with it over the next few days, really only need simple toggles though but I'll test what I can. Do you plan, in the future, to allow us to change the ToggleConfigurationSettings prefix (the key it is searching for)? With the JSON format, it would be handy to take advantage of the nested format, so { "FeatureToggle": { "TestFeatureToggle": "true" } } The key will be FeatureToggle: instead of FeatureToggle. Thanks for the ASP.NET Core support.

[jason-roberts]

Thanks @steventmayer - certainly open to suggestion around the json config format :)

[steventmayer]

After playing with the newest build, I was thinking of the ability to set the ToggleConfigurationSetting through an alternate constructor when you create the AppSettingsProvider, allowing you to set prefix that way. Another option would be to allow the user to set a configuration key through a custom attribute. This would allow flexibility in the different Configuration frameworks. I'll try out some options if I can get time.

[djjlewis]

Hi @jason-roberts I've just started looking at using your library in out web application. It is written on ASP.NET Core, but we are currently targetting the full framework (net461) due to a couple of 3rd party libraries that do not currently support netcore / netstandard. While trying to follow your asp.net core sample project, I noticed I did not have access to the Configuration property of the AppSettingsProvider, and a quick glance at the source looks like this is being removed due to a preprocessor directive.

I must say I haven't had time to look into this in too much detail, so apologies if I have missed something fundamental, but ordinarily, all the NETCORE parts should in theory work on the full framework, whereas the other way around may not be true (NETFULL may not work on NETCORE).

From what I can see, I think the reasoning is that you are implicitly choosing how the config is read depending on which framework is being targetted, whereas I think it would be nice if one could choose to use the asp.net core Configuration support regardless of the framework being targetted?

If you agree, and if I get chance I will see if I can have a look myself and send a PR, but am just a bit up against it time-wise atm as I am sure many of us are!

[jason-roberts]

Just released rc3 to nuget https://www.nuget.org/packages/FeatureToggle/4.0.1-rc3

No feature changes, just repackaged FeatureToggle.NetStandard as FeatureToggle.Common https://www.nuget.org/packages/FeatureToggle.Common/

[jason-roberts]

Hi all, I'm thinking we could release this rc3 as final 4.0.0.0 RTM release (before looking at the config enhancement that @djjlewis suggested https://github.com/jason-roberts/FeatureToggle/issues/146 ), has anyone testing the new rc3 packages? thanks :)

/ @fleed @calloncampbell @Assassyn @mehalick @steventmayer @djjlewis

[maykelmtzd]

Hi Jason, I am facing the same issue mentioned on #146 Do you have an idea on when are you going to release 4.0.0.0 where we could access the Configuration property from projects that don't target .netcore?

I guess for the moment I'll have to implement my own version of AppSettingsProvider...

Thanks!

[jason-roberts]

RTM for v4.0.2 just released to NuGet.

[bluefivecn]

Hi Jason, I am getting the following error when installing FeatureToggle 4.0.2. Is there any plan for supporting netstandard1.6?

Package FeatureToggle 4.0.2 is not compatible with netstandard1.6 (.NETStandard,Version=v1.6).

Thanks!

[jason-roberts]

Hi @bluefivecn - please see here https://github.com/jason-roberts/FeatureToggle/issues/46#issuecomment-365833924 . v4 timeframe was to get initial support for people asking for .net core support.

[bluefivecn]

@jason-roberts Thank you!

[CumpsD]

@jason-roberts an old issue, but could you target netstandard instead of netcoreapp? Since this is a library I dont understand why it would have to be an app. Now every library of ours who uses FeatureToggle has to be turned into a netcoreapp as well, viral :)