Update to dotnet core 1.0.0 about specflow.netcore HOT 12 CLOSED

I just used this package. Works great; thank you, @erik-lundgren . Hopefully the PR will happen (need a hand?) and we can get this onto NuGet - using private feed currently.

from specflow.netcore.

https://www.nuget.org/packages/SpecFlow.NetCore/1.0.0-alpha1

from specflow.netcore.

I've added the support and a copy of your sample project updated to asp.net core 1.0.0 in my fork at https://github.com/erik-lundgren/SpecFlow.Dnx/tree/dotnetcore if you want to have a look.

from specflow.netcore.

👍

Yes, happy to take a PR! I haven't updated to RTM yet myself (on my list), so I'll blindly merge it in if you are okay with supporting it.

from specflow.netcore.

Hey @smudge202!

Thank you for the kind words. I'll be trying to make the PR happen during this weekend. I think the docs need a slight update and there's possibly a better way to do this as currently the tests are not discovered unless you build twice. If anyone knows how to make the tests discoverable after the first build please let me know :)

from specflow.netcore.

The docs will be easy to update. I also have to update references from dnx > dotnet.

The build twice thing: is that new for dotnet?

from specflow.netcore.

I hadn't noticed it was double building. Will investigate also (shouldn't be necessary).

from specflow.netcore.

It's not double building. Currently it executes during pre-compile as I assumed this would be before build and before test discovery. However when generating files for the first time in a project the tests do not get discovered. To repro, remove the "precompile": [ "dotnet specflow" ] line in the scripts section of my sample project, delete any .feature.cs files and rebuild the project. No tests should (correctly) have been discovered at this point. Now, add the line, back, rebuild the project. No tests have still been discovered (incorrect). Rebuild again, now the tests appear.

It seems it has to do with new files being added to the project, as when you change the .feature files those changes are picked up immediately. I'll add an issue for this if I get the pull request accepted.

from specflow.netcore.

Hmm, sounds a bit weird. Yeah add an issue for it and can check it out later. I've merged in the PR (#20) but I'll leave this open until I've got the package up on nuget.org, dependent on renaming things (#21).

from specflow.netcore.

Since I had renamed the repo and package, I thought I would restart the version numbering (hence alpha1). However the repo rename is a lie, and the git history still keeps existing tags - the latest tag being beta2. So to avoid a weird state where the most recent code has a tag that is before older code, I thought fuck it and re-tagged it RC!

https://www.nuget.org/packages/SpecFlow.NetCore/1.0.0-rc1

from specflow.netcore.

Bearing in mind that the aspnetcore dependencies are RTM now (and specflow is stable) should this package be using an alpha/beta tag?

from specflow.netcore.

Probs not. I'll get rid of it soon.

from specflow.netcore.