Consider netcoreapp ONLY compatiblity

smudge202

Following on from [this comment](https://github.com/stajs/SpecFlow.NetCore/issues/65#issuecomment-356999811) I wonder if it would be worthwhile making `netcoreapp` a reality. Consider the following flow: 1. If test project is not pulling down SpecFlow, download a copy ourselves * If the test project multi-targets `netcoreapp` *and* one of the full fat framework versions, it's possible the user has a conditional dependency (or they're getting build warnings because SpecFlow is only available on `net45`) 1. Generate the legacy csproj as we do now 1. Run SpecFlow against legacy csproj as we do now 1. Drop csproj and specflow install if we downloaded it for user 1. ... 1. $$$ The only real difference in the existing flow is step 1 and a bit of step 4. It's not pretty, but it would mean `netcoreapp` would work as intended? **Caveats** * If the user is multi-targeting and using compiler directives (`#ifdef NETCORE` for example) in the test project, then the code that SpecFlow executes against would potentially be inconsistent (because we'll only ever compile the `net45` variant for SpecFlow.exe). Though, that's probably true already because I don't think we copy conditional directives to the build configuration of the generated csproj? * If trying to run `netcoreapp` outside of windows or without `net45`+ being available, it'll fail because the sneaky execution of SpecFlow won't be possible. Would potentially decrease the confusion around this project (because it would be living up to it's name instead of being a bridge that allows new style csproj only) and reduce the number of issues? Food for thought.

stajs

I admire the creativity (really!) and I'm somewhat intrigued by the challenge, but ultimately I think it's a bridge too far. The caveats: - I'm not multi-targeting so I don't know, but I think compiler directives would be fine considering the hackery is all during precompile. You can't add them to feature files for them to be translated and the generated csproj isn't used for the actual build. - Yeah, this failure to me means we should scale it back and be clearer about the SpecFlow/Windows/.NETFramework dependencies. I agree, the naming confusion is a problem and I think [it's worth doing something about that](https://github.com/stajs/SpecFlow.NetCore/issues/65#issuecomment-357926503). I'm ever-hopeful that SpecFlow will come out with .NET Core support itself and this project can be retired (I've a thought to how we can ease the transition off this tool when the time comes).

stajs

#69