Attempt to reduce the confusion of the project name

[stajs]

I feel the need to unload some history first...

Before .NET Core and ASP.NET Core, there was DNX and ASP.NET 5 and this project was known as https://github.com/stajs/SpecFlow.Dnx. At least back then it was somewhat clear that a DNX app could target full .NET Framework or the newfangled .NET Core.

http://dotnet.today/en/aspnet5-vnext/conceptual-overview/dotnetcore.html

The .NET Execution Environment (DNX) provides a cross-platform runtime host that you can use to build .NET Core based applications that can run on Windows, Mac and Linux and is the foundation for running ASP.NET applications on .NET Core. Applications running on DNX can target the .NET Framework or .NET Core.

The marketing rebadging of DNX has overloaded the meaning of .NET Core, essentially making that last sentence:

Applications running on DNX .NET Core can target the .NET Framework or .NET Core.

Fast forward to now:

https://docs.microsoft.com/en-us/dotnet/core/packages

.NET Core is a platform made of NuGet packages.

Each of the .NET Core packages support being run on multiple .NET implementations, represented as frameworks. Some of those frameworks are traditional frameworks, like net46, representing the .NET Framework.

Okay, so still the same idea as before.

---

So, the problem

An app using .NET Core packages can run on net*, but a lot of newcomers to .NET Core reasonably expect this package to also run on netcoreapp*.

The limited best we can do to show that SpecFlow limits us to net451+

• Improve the README.
• Remove the .NETCoreApp 2.0 package dependency.
  

[smudge202]

Nice write-up. Hopefully we can get the package + readme in such a state that things are a little clearer for newcomers.

[stajs]

@smudge202 Care to review the README changes?

[smudge202]

Ironically, this sentence I had to read a couple times to grasp:

If you find it confusing that this project includes "NetCore" in the name, yet it only supports .NET Framework and not .NET Core Application, remember the above limitation of SpecFlow and that it is a legitimate usage of a .NET Core package:

I wonder if something along the lines of this would be any easier for people to digest:

The reason this project is named "SpecFlow.NetCore" is not because we support the netcoreapp platforms, but instead because we allow for the new style tooling (like the new csproj format) that was introduced with .Net Core. Support for the netcoreapp platform (and other non-Full Framework platforms) is completely constrained by development of the SpecFlow project which you can contribute to here <-- insert a link.

I would also be tempted to move that entire section above the Solution section so it appears much earlier in the readme. Many people won't read past the "this code samples gets you up and running" bit.

Otherwise, looks good.

[stajs]

Thanks for your feedback. You wouldn't believe how long it took me to "simplify" the message while trying to be technically accurate with the terminology. I like what you've come up with and I'll try to appropriate some of it. I'm trying to be consistent with the official docs where "Platform" means OS and netcoreapp is a TFM of a target framework. It's not easy for newcomers or latecomers!

[smudge202]

Just poking this issue because I brought up the project on twitter today - in case there's a small influx of people curious about this.

https://twitter.com/Smudge202/status/963374877309796352

[stajs]

Cool, thanks for the bump!

I struggled with the overcomplicated defense of the naming. It got way too verbose making the point harder to grok. In the end, I don't think people care about the technical legitimacy of the project name over whether they can use this thing with their project. So rather than delve in to the detail, I've just bullet-pointed the supported/unsupported frameworks. I'm happy with it now, but I'm open to any further suggestions.

Also, I've moved the warning/callout to the top of the README as you suggested.

[stajs]

#85 (comment)