Hi, after the update to version 15.7.1 of VS 2017, the build task that updates the auto-generated code files is not being called in case of changes in .feature files. This seems related to the optimizations done in VS to reduce build time of large projects. The only way to force it to build is if I change a code (.cs) file or the project file (.csproj).

My solution has 52 projects and if I change only a feature file, the following text is shown in build output window:

========== Build: 1 succeeded, 0 failed, 52 up-to-date, 0 skipped ==========

I'm trying to find an workarround for this, but until now I was unable to do. Someone is also experiencing the same issue?

Both xunit and the xunit.runner.dnx support dnx451 and is likely to catch people out despite the supported framework section in the readme. I'll have a quick look at implementing this.

Yeah, best issue title ever. This is just a placeholder so I remember to do some digging.

For alpha8, the dependencies are this:

For alpha9, they became this:

Yes I know, dnx46 is based on full .NET Framework 4.6. I wonder if I need to have multiple TFMs in the library now.

I would like the generated Feature.cs files to be in the namespace of the current project and not the fake SpecFlow.GeneratedTests.

As per my comment on a previous issue, it would be good to get the Produce output on builds info added to the readme. In addition, I think the follow two tips would be great:

To automate testing of your specs:

• In project.json, add a dependency to xunit.runner.dnx (at time of writing, version 2.1.0-rc1-build204).
• Add a second command (in addition to the one used by the prebuild element) as follows:

"test": "xunit.runner.dnx"

This will make your specs appear in test explorer.

The overall output will be along the lines of:

{
    "version": "1.0.0-*",
    "commands": {
        "create-specs": "SpecFlow.Dnx",
        "test": "xunit.runner.dnx"
    },
    "scripts": {
        "prebuild": "dnx create-specs"
    },
    "frameworks": {
        "dnx46": {
            "dependencies": {
                "SpecFlow.Dnx": "1.0.0-alpha8",
                "xunit": "2.1.0",
                "xunit.runner.dnx": "2.1.0-rc1-build204"
            }
        }
    }
}

The above is obvious if you've ever done work with DNX in the past, but for people entering the arena it would be helpful I'm sure.

Hi.
Thank you for the lib. It's good temporary solution for Net Core.

I have a problem.

When I generate step from feature and put them in root of the project. They are detected with no issues and binding is working too:

But when I put steps in subfolder they are become invisible for feature file and binding is not working:

Do you have any idea how to fix it?
I've tried to play with namespaces and tried to add steps cs files to fake.csproj but nothing fixed it.

The readme needs to be updated to cover for the dot net core tools configuration.

I may have time to do this during the week as there are only a few things that have changed. Otherwise I'll look into it during the weekend.

Was just reading through the README updates (GJ 👍), noticed that we still state:

however (at time of writing) no other test frameworks are available for .NET Core.

This is no longer true, MsTest has been available since RC2.

We should probably test if an app.config change is enough to make things work as intended. Docs may also need updating to reflect the two frameworks, perhaps even allow a command line arg to be passed to the program to determine which framework is in use?

"precompile": [ "dotnet SpecFlow.NetCore xunit" ]

Also, though I haven't used it, looks like nunit finally supports Net Core.

When adding test files to a project the tests do not get picked up on first build, but they are picked up when rebuilding.

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.

This may be a dotnetcore issue because I see slightly similar behaviour when just adding new non-specflow tests to my project (tests being discovered but not ran in that case), but should still be looked into.

Specifically, should the samples here mimic: https://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop but with dnx451 / dnx46?

Note, we should probably ask the TechTalk guys if we decide to provide a DNX version of their samples.

Hi everyone !

I try to work with Specflow 2.0, localization and SpecFlow.Dnx with recommended configuration :

https://github.com/stajs/SpecFlow.Dnx

For my sample, I use this project on SpecFlow.Dnx github :

https://github.com/stajs/SpecFlow.Dnx/tree/master/samples/VS2015/SpecFlow%201.9.0/dnx46%201.0.0-rc1-final

By default, the project use default localization (en-US).
When I change the localization to french (fr-FR), I have an error :

Folder\Folder.feature -> test generation failed

Here is my feature changed :

# language: fr-FR
Fonctionnalité: Feature in folder

Plan du scénario: SpecFlow glue files are generated
    Etant donné I am curious
    Quand I request the version
    Alors the result is constant

Here is my app.config with culture defined :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
        <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
    </configSections>
    <specFlow>
    <language feature="fr-FR" />
    <bindingCulture name="fr-FR" />
        <unitTestProvider name="xUnit" />
    </specFlow>
</configuration>

If this feature works in english (with english keyword of course), why it doesn't work in french ?
It seems there is an error with letters with accent.

I tried to debug specflow tools code, and I have an error at this line (class SpecFlowGherkinParser method Parse) :
var feature = parser.Parse(new TokenScanner(featureFileReader), tokenMatcher);

Thank you for your help.

Greg

Hi guys, I think it's great you are doing this until TechTalk fixes it. I am trying to port a test project using NUnit over to net core and I think I am close, but I get a test error and it doesn't discover my tests. Output is:

------ Discover test started ------  
Discovering tests in 'C:\Projects\myProj\project.json' ["C:\Program Files\dotnet\dotnet.exe" test "C:\Projects\myProj\project.json" --output "C:\Projects\myProj\bin\Debug\net452\win7-x64" --port 39182 --parentProcessId 8364 --no-build]  
'test-nunit' returned '-100'.  
========== Discover test finished: 0 found (0:00:00.6919996) ==========  

project.json is (abridged ... ):

{
    "version": "1.0.0-0",

    "testRunner": "nunit",

    "dependencies": {
        ...
        "SpecFlow": "2.1.0",
        "SpecFlow.NUnit": "2.1.0",
        "SpecFlow.NUnit.Runners": "2.1.0",
        "dotnet-test-nunit": "3.4.0-beta-2",
    },
    "frameworks": {
        "net452": {
            "dependencies": {
                ...
            },
            "frameworkAssemblies": {
                "System.Configuration": "4.0.0.0"
            }
        }
    },
    "runtimes": {
        "win-x64": {}
    },
    "tools": {
        "SpecFlow.NetCore": "1.0.0-rc4"
    },
    "scripts": {
        "precompile": [ "dotnet SpecFlow.NetCore" ]
    }
}

Currently, the specflow.netcore package only targets NetCoreApp1.0. However, the specflow package itself is not available in NetCoreApp's.

So, for example, these project.json's both fail:

{
  "dependencies": {
    "dotnet-test-xunit": "2.2.0-preview2-build1029",
    "specflow": "2.1.0",
    "specflow.netcore": "1.0.0-rc1",
    "xunit": "2.2.0-beta2-build3300"
  },
  "tools": {
    "dotnet-specflow": "1.0.0-rc1"
  },
  "testRunner": "xunit",
  "frameworks": {
    "net461": {}
  },
  "scripts": {
    "precompile": [ "dotnet specflow" ]
  }
}

Fails because specflow.netcore does not support net461.

{
  "dependencies": {
    "dotnet-test-xunit": "2.2.0-preview2-build1029",
    "specflow": "2.1.0",
    "specflow.netcore": "1.0.0-rc1",
    "xunit": "2.2.0-beta2-build3300"
  },
  "tools": {
    "dotnet-specflow": "1.0.0-rc1"
  },
  "testRunner": "xunit",
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.0.0"
        }
      }
    }
  },
  "scripts": {
    "precompile": [ "dotnet specflow" ]
  }
}

Fails because specflow does not support netcoreapp.

Before the change to netcore, we could get this to work as follows:

{
  "dependencies": {
    "dotnet-test-xunit": "2.2.0-preview2-build1029",
    "specflow": "2.1.0",
    "specflow.dnx": "1.0.0-beta3",
    "xunit": "2.2.0-beta2-build3300"
  },
  "tools": {
    "dotnet-specflow": "1.0.0-beta3"
  },
  "testRunner": "xunit",
  "frameworks": {
    "net461": {}
  },
  "scripts": {
    "precompile": [ "dotnet specflow" ]
  }
}

NB: I was using an internal build of @erik-lundgren's netcore migration at the time of the above.

Specflow itself doesn't actually specify targets on the NuGet page (I hate that), however you can see from the package itself that it only has a net45 lib folder (therefore only available with the full .Net 4.5+).

Whilst it would be nice for the main specflow package to get this all sorted, but the primary purpose of specflow.dnx/netcore is to provide a bridge in the interim. Therefore, I suspect what we want is to aim for something akin the last project.json I provided above? Perhaps @erik-lundgren can comment?

Running CLI tool "dotnet SpecFlow.NetCore" fails on Linux (dotnet core 2.0).

Error: value cannot be null (Parameter name: path1)

The command "dotnet SpecFlow.NetCore" exited with code 255.

Shouldn't this also work on linux?

When I execute dotnet SpecFlow.NetCore I get the following error message:

λ dotnet SpecFlow.NetCore
Error: Can't find SpecFlow: ...\.nuget\packages\SpecFlow\2.1.0\tools\specflow.exe
Try specifying the path with --specflow-path.

The correct path is ~\.nuget\packages\SpecFlow\2.2.1\tools\specflow.exe. Please update the version. thx!

I tried the manual step but still fail :-( do you have any idea to fix it ?

Thanks

If a previous build has failed to clean up the fake.csproj file, new builds will not work, even if the issue that caused the fake.csproj file to remain is fixed.

I had an error in a feature-file, which stopped SpecFlow.NetCore from generating all the x.feature.cs-files but the fake.csproj-file had been generated. Visual Studio displayed
MSB3073 The command "dotnet SpecFlow.NetCore" exited with code 1.
so it was not apparent what the actual issue was. Once I removed the fake.csproj-file and manually ran dotnet SpecFlow.NetCore I could see the actual cause of the issue.

It's easy to reproduce, just create an empty file next to the csproj for the project running specflow and name whatever.csproj.

Hi, would be great to create new NuGet package, at least pre-release, so we can check all the changes on our projects without creating our own NuGets from forks.

Thanks!

As per discussion on #28 and a previous PR, can we do something regarding formatting. Personally I recommend an .editorconfig approach, which requires a small extension be installed to VS (though works natively in VSCode).

The extension is here: https://visualstudiogallery.msdn.microsoft.com/c8bccfe2-650c-4b42-bc5c-845e21f96328

Once installed, simply add an editorconfig file as per the description on that page to have everyone share the format settings. (Personally I prefer to Keep Tabs with a tab space of 4 for c#, but it doesn't matter so long as solution level settings are shared).

2016-02-12T10:36:30.8956466Z (CoreCompile target) ->
2016-02-12T10:36:30.8956466Z C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DNX\Microsoft.DNX.targets(158,5): error : 'dnx' is not recognized as an internal or external command, [C:\a\1\s\Source...AcceptanceTests...AcceptanceTests.xproj]
2016-02-12T10:36:30.8966458Z C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DNX\Microsoft.DNX.targets(158,5): error : operable program or batch file. [C:\a\1\s\Source...AcceptanceTests...AcceptanceTests.xproj]
2016-02-12T10:36:30.8966458Z C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DNX\Microsoft.DNX.targets(158,5): error : The 'prebuild' script failed with status code 1. [C:\a\1\s\Source...AcceptanceTests...AcceptanceTests.xproj]

I am running the PreBuild.ps1 script prior to the solution build, as described at:

https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5

The dnu restore is working as expected in the PreBuild.ps1 script, but dnx is unavailable as part of the prebuild script.

Solution works great, and is a clever workaround until SpecFlow catches up. I only have a problem binding "dnx specflow-dnx" as a prebuid script step. It works fine when run with command line, but not automatically in VS. How did you get the prebuild step to fire for you?

I have the following setup:

"dependencies": {
"SpecFlow": "2.2.0-preview20161020",
"dotnet-test-mstest": "1.1.2-preview",
"FluentAssertions": "4.17.0",
"Microsoft.AspNetCore.TestHost": "1.1.0",
"MSTest.TestFramework": "1.0.7-preview",
"Microsoft.AspNet.WebApi.Client": "5.2.2"
},
"tools": {
"SpecFlow.NetCore": "1.0.0-rc7"
}

I receive the following error:
Can't find SpecFlow: C:\Users...\.nuget\packages\SpecFlow\2.1.0\tools\specflow.exe

Is SpecFlow.NetCore 1.0.0-rc7 dependent directly on version 2.1 of SpecFlow?

Thank you, George

In SpecFlow you can use bindings from external assemblies

I'm using this to use import step bindings from a NuGet package. It worked with an old-fashioned .Net 4.6 solution, but not when I use .Net Core and this library.

I added the <stepAssemblies> to the app.config file that is generated by SpecFlow.NetCore.

I followed the instructions and get the following error:

The tools version "14.0" is unrecognized. Available tools versions are "2.0", "3.5", "4.0".

the .csproj file looks like the following:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.3.0" />
    <PackageReference Include="NUnit" Version="3.7.1" />
    <PackageReference Include="SpecFlow.NetCore" Version="1.0.0-rc8" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="SpecFlow.NetCore" Version="1.0.0-rc8" />
  </ItemGroup>
  <Target Name="PrecompileScript" BeforeTargets="BeforeBuild">
    <Exec Command="dotnet SpecFlow.NetCore" />
  </Target>
</Project>

I also get the following output:

New file generated: C:\Users\...\XYZ.feature.cs. No tests in XYZ.feature will be discovered by 'dotnet test'

But the file is not generated in the folder specified.

Running the XUnit sample with mono, The dotnet SpecFlow.NetCore seems to work as expected:

dotnet SpecFlow.NetCore
  Current directory: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit
  Found: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Sample.Website.Tests.XUnit.csproj
  Found: /Users/alelog01/.nuget/packages/specflow/2.1.0/tools/specflow.exe
  Generating fake csproj.
  <?xml version="1.0" encoding="utf-8"?>
  <Project ToolsVersion="" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  	<PropertyGroup>
  		<RootNamespace>SpecFlow.GeneratedTests</RootNamespace>
  		<AssemblyName>SpecFlow.GeneratedTests</AssemblyName>
  	</PropertyGroup>
  	<ItemGroup>
  		<None Include="app.config">
  			<SubType>Designer</SubType>
  		</None>
  		<None Include="Root.feature">
  			<Generator>SpecFlowSingleFileGenerator</Generator>
  			<LastGenOutput>/Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Root.feature.cs</LastGenOutput>
  		</None>
  		<None Include="Folder/Folder.feature">
  			<Generator>SpecFlowSingleFileGenerator</Generator>
  			<LastGenOutput>/Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Folder/Folder.feature.cs</LastGenOutput>
  		</None>
  	</ItemGroup>
  </Project>
  Saving: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Sample.Website.Tests.XUnit.csproj.fake
  Found xunit in /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Sample.Website.Tests.XUnit.csproj
  Generating app.config
  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
  	<configSections>
  		<section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
  	</configSections>
  	<specFlow>
  		<unitTestProvider name="xunit" />
  	</specFlow>
  </configuration>
  Saving: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/app.config
  Validating app.config.
  Found xunit in /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Sample.Website.Tests.XUnit.csproj
  Calling: /Users/alelog01/.nuget/packages/specflow/2.1.0/tools/specflow.exe generateall "/Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Sample.Website.Tests.XUnit.csproj.fake" /force /verbose

  Removing: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Sample.Website.Tests.XUnit.csproj.fake
  Fixing SpecFlow generated files
  New file generated: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Root.feature.cs. No tests in Root.feature will be discovered by 'dotnet test'
  New file generated: /Users/alelog01/specflowTest/SpecFlow.NetCore/samples/VS2017/SpecFlow 2.1.0/net461/Sample.Website.Tests.XUnit/Folder/Folder.feature.cs. No tests in Folder.feature will be discovered by 'dotnet test'
  Rebuild to make the above files discoverable, see https://github.com/stajs/SpecFlow.NetCore/issues/22.
  SpecFlow fixed.

However no files are generated. SpecFlow should work with mono so is any further configuration needed to get this to work?

I have a weird issue. When I run dotnet build on CI feature files are not generated due to the error:

Found mstest in C:\buildAgent\work\67171554868c3343\IntegrationTests\IntegrationTests.csproj
Calling: C:\Users\Administrator.nuget\packages\SpecFlow\2.4.0\tools\specflow.exe generateall "C:\buildAgent\work\67171554868c3343\IntegrationTests\IntegrationTests.csproj.fake" /force /verbose
TechTalk.SpecFlow 2.4.0-ci.51+Branch.master.Sha.b0e03e46d1fc3a27a66b3956ea0da2d90b5c4444
Copyright c TechTalk 2011
ERROR(S):
Required option 'p, ProjectFile' is missing.

Whereas locally -p option is specified.

Calling: C:\Users\pavelvoronin.nuget\packages\specflow\2.4.0\tools\specflow.exe generateall -p "C:\Users\pavelvoronin\Source\Repos\integration.tests.dotnet\IntegrationTests\IntegrationTests.csproj.fake" --force --verbose
Processing project: IntegrationTests.csproj

Versions of specflow.exe are identical: 2.4.0-ci.51+Branch.master.Sha.b0e03e46d1fc3a27a66b3956ea0da2d90b5c4444

What may be the reason for this oddity?

When adding a new test step there's no longer the "nice" output with the "Test pending" and the example code missing, rather there's an error related to nunit.framework

To reproduce just add a step to the "Specflow glue files are generated" tests like And temp, build and run the tests. the error is something like Could not load file or assembly 'nunit.framework' or one of its dependencies.

Some googling makes me believe this crops up if the SpecFlow config isn't explicitly set to use a specific framework.

First step to get back would be to add support for xunit, but as dotnet core now also supports mstest maybe we should try to also support that (I don't know of any other test frameworks). What's your opinion, as this package is only here until specflow releases their official stuff?

See #15.

Following on from this comment 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)
2. Generate the legacy csproj as we do now
3. Run SpecFlow against legacy csproj as we do now
4. Drop csproj and specflow install if we downloaded it for user
5. ...
6. $$$

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.

Hello stajs,

Are you interested in an update of this package for the new dotnet clr?

I've made updates so that it works with the new cli locally on my computer.

I'll gladly make a pull request if you'd like so that you can add it to nuget as a separate package.

dotnet core (nuget 3.2+) uses the environment variable NUGET_PACKAGES to identify where to store and read local nuget packages.

Support for both could be really useful - especially on a build server.

Can you provide a sample that works with no net461 framework references in the project.json files? Or is this simply not possible due to Specflow package dependencies?

This no longer seems to work now that the dotnet test cli has changed for dotnet core 2. Any plans to update it?

Hi,

I'm trying to get Specflow working with VS Code and .Net core targeting net461 hoping you might have tried this already!

But I'm struggling to get the feature code behind .cs to generate?

I've added in the specflow targets but was not sure your approach could be adapted?

After importing the targets I get the error below - assuming this must be .net core mismatch?

   "C:\temp\canopyTest\canopyTest.csproj" (Build target) (1) ->
   (UpdateFeatureFilesInProject target) ->
     C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061: The "GenerateAll" task could not be instantiated from "C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\specflow.exe". \r [C:\temp\canopyTest\canopyTest.csproj]
   C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061: System.TypeLoadException: Could not load type 'System.MarshalByRefObject' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.\r [C:\temp\canopyTest\canopyTest.csproj]
   C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061:    at Microsoft.Build.Utilities.Task..ctor()\r [C:\temp\canopyTest\canopyTest.csproj]
   C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4061:    at TechTalk.SpecFlow.Tools.MsBuild.GenerateAll..ctor() [C:\temp\canopyTest\canopyTest.csproj]
     C:\Users\richard\.nuget\packages\SpecFlow\2.2.0-preview20161020\tools\TechTalk.SpecFlow.targets(47,5): error MSB4060: The "GenerateAll" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name. [C:\temp\canopyTest\canopyTest.csproj]

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.
  

Remove hardcoded SpecFlow version (2.1.0):

As a temp fix, copy SpecFlow to yout project folder ie .\_tools\SpecFlow\ and use this MsBuild task:

<Exec Command="dotnet SpecFlow.NetCore --specflow-path $(MSBuildThisFileDirectory)_tools\SpecFlow\specflow.exe" />

• Rename repo.
• File/folder names.
• Namespaces.
• Rename NuGet.

I'm not sure of the best way to face this and appreciate that the project itself is (hopefully) just a workaround pending better support from the specflow VS extension.

I've only used specflow for a month or two now, and would typically copy the step definitions for a given feature to the clipboard and paste them in my choice of step file. As far as I can tell, this isn't possible within a DNX project using this workaround.

How do you achieve this currently, @stajs ? More to the point, is there a way to workaround the step definition issue? The only thing I can think of is if SpecFlow.Dnx is able to consume additional command(s) for step definition generation? One possible solution would be to hijack the clipboard during build (copy any undefined steps to clipboard)?

I know that's not ideal but struggling to think of a good workaround.

I cannot add feature file in .net core project. Do I need to install specifically for .net core?

project.json

{
  "version": "1.0.0-*",

  "dependencies": {
    "SpecFlow.NetCore": "1.0.0-rc5",
    "xunit": "2.2.0-beta2-build3300",
    "dotnet-test-xunit": "2.2.0-preview2-build1029"
  },

  "tools": {
    "SpecFlow.NetCore": "1.0.0-rc4"
  },

  "testRunner": "xunit",

  "scripts": {
    "precompile": [ "dotnet SpecFlow.NetCore" ]
  },
  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

`

I've been trying to understand what this means for a couple of days now. My understanding (probably totally wrong) was that i could use VS2017 to develop a DOTNET CORE class library and then test it using another DOTNET CORE Test Project, using the SpecFlow.NetCore NuGet package (and modifications to the app.config).

The behaviour appears conflicting.

The .feature.cs gets generated but the Techtalk.Specflow library is missing.

If I include SpecFlow 2.1.0 the build fails with incompatible .net versions.

Am I simply trying to use this in an impossible way or is there a workaround.

We use Specflow universally and a attempting to start a DOTNET CORE project right now and failing miserable.

Thnaks

Specflow generator is trying to use Xunit.Extensions.TheoryAttribute and Xunit.Extensions.InlineDataAttribute, however these attributes have been rolled into the core Xunit namespace in 2.0, and Xunit.Extensions does not support DNX...

I haven't diagnosed whether this is a result of the dnx integration or there's another cause yet.

To reproduce, follow the guide in the readme to get everything up and running (love that readme). Then add a "@tag" to a scenario and build for test discovery. If you group by traits in the test explorer you'll see all scenarios are listed without traits. Normally they'd have half a dozen such as the feature name.

The xunit sample in this repository does not build spec.cs files on my machine.

Withing the build output there is a call to specflow.exe generateall and it generates the following error:

The tools version "14.0" is unrecognized. Available tools versions are "2.0", "3.5", "4.0".  D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj.fake.csproj

I receive the same error from the developer command line using a manually created 'fake.csproj' file.

Is the issue caused because I only have Visual Studio 2017 on my machine? Does the project build successfully on machines with VS 2015 installed as well?

I'm aware of Issue #49 but that issue was closed because Target Framework is not supported.

Full build log.

Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Rebuild All started: Project: Sample.Website, Configuration: Debug Any CPU ------
1>Sample.Website -> D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website\bin\Debug\net461\win7-x86\Sample.Website.exe
2>------ Rebuild All started: Project: Sample.Website.Tests.XUnit, Configuration: Debug Any CPU ------
2>Found: C:\Users\tim\.nuget\packages\SpecFlow\2.1.0\tools\specflow.exe
2>Current directory: D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit
2>Found: D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj
2>Generating fake csproj.
2><?xml version="1.0" encoding="utf-8"?>
2><Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
2>	<PropertyGroup>
2>		<RootNamespace>SpecFlow.GeneratedTests</RootNamespace>
2>		<AssemblyName>SpecFlow.GeneratedTests</AssemblyName>
2>	</PropertyGroup>
2>	<ItemGroup>
2>		<None Include="app.config">
2>			<SubType>Designer</SubType>
2>		</None>
2>		<None Include="Root.feature">
2>			<Generator>SpecFlowSingleFileGenerator</Generator>
2>			<LastGenOutput>Root.feature.cs</LastGenOutput>
2>		</None>
2>		<None Include="Folder\Folder.feature">
2>			<Generator>SpecFlowSingleFileGenerator</Generator>
2>			<LastGenOutput>Folder.feature.cs</LastGenOutput>
2>		</None>
2>	</ItemGroup>
2></Project>
2>Saving: D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj.fake.csproj
2>Found xunit in D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj
2>Validating app.config.
2>Found xunit in D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj
2>Calling: C:\Users\tim\.nuget\packages\SpecFlow\2.1.0\tools\specflow.exe generateall "D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj.fake.csproj" /force /verbose
2>The tools version "14.0" is unrecognized. Available tools versions are "2.0", "3.5", "4.0".  D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj.fake.csproj
2>
2>Removing: D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Sample.Website.Tests.XUnit.csproj.fake.csproj
2>Fixing SpecFlow generated files
2>New file generated: D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Root.feature.cs. No tests in Root.feature will be discovered by 'dotnet test'
2>New file generated: D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\Folder\Folder.feature.cs. No tests in Folder.feature will be discovered by 'dotnet test'
2>Rebuild to make the above files discoverable, see https://github.com/stajs/SpecFlow.NetCore/issues/22.
2>SpecFlow fixed.
2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1987,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website\bin\Debug\net461\win7-x86\Sample.Website.exe", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
2>Sample.Website.Tests.XUnit -> D:\Downloads\SpecFlow.NetCore-master\SpecFlow.NetCore-master\samples\VS2017\SpecFlow 2.1.0\net461\Sample.Website.Tests.XUnit\bin\Debug\net461\Sample.Website.Tests.XUnit.dll
2>Done building project "Sample.Website.Tests.XUnit.csproj".
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========

It does not support netcoreap1.0 - 1.1, you are still targeting .net framework 4.6.1 hence you should not call this .netcore...

Now we have the 1.0.0 than supports .netcore 2.0
Could you provide me an example of how I can run the test in the CLI?
I'm trying:

dotnet ./packages/SpecFlow.NetCore/lib/netcoreapp2.0/dotnet-SpecFlow.NetCore.dll -- --verbose

How I can specify the assembly to test?

Version: 1.2.0

Related to SpecFlowOSS/SpecFlow#1002

I have Windows development machine. Everything is working ok.
I also have Windows build agent. Nothing works :) Log is below. How do I debug/fix this?

PS C:\BuildAgent\work\1cdf652514f12572\backend> dotnet --info
.NET Command Line Tools (2.0.3)

Product Information:
 Version:            2.0.3
 Commit SHA-1 hash:  12f0c7efcc

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.3\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

PS C:\BuildAgent\work\1cdf652514f12572\backend> dotnet build .\tests\services.SpecFlow\services.SpecFlow.csproj
C:\BuildAgent\work\1cdf652514f12572\backend\tests\services.SpecFlow\services.SpecFlow.csproj : warning NU1701: Package 'SpecFlow 2.1.0' was restored using '.NETFramework,Version=v4.6.1' instead of the pr
oject target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.


  Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Threading, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest
definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
     at System.Console.get_Out()
     at System.Console.WriteLine(String value)
     at SpecFlow.NetCore.Program.PrintUsingColor(String message, ConsoleColor newColor)
     at SpecFlow.NetCore.Program.Main(String[] args)
C:\BuildAgent\work\1cdf652514f12572\backend\tests\services.SpecFlow\services.SpecFlow.csproj(92,5): error MSB3073: The command "dotnet SpecFlow.NetCore" exited with code -532462766.

Build FAILED.

C:\BuildAgent\work\1cdf652514f12572\backend\tests\services.SpecFlow\services.SpecFlow.csproj(92,5): error MSB3073: The command "dotnet SpecFlow.NetCore" exited with code -532462766.
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:03.12
PS C:\BuildAgent\work\1cdf652514f12572\backend>

#The following scenario name demonstrates the problem with long names
Scenario: This is an example of a case that will fail when the amount of characters in the scenario names goes beyond 80 characters
When using the original specflow exe to create cs files this results in the following glue code

[Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute()]
[Microsoft.VisualStudio.TestTools.UnitTesting.DescriptionAttribute("This is an example of a case that will fail when the amount of characters in the " +
"scenario names goes beyond 80 characters")]

The FixMsTest function uses a regex to remove the Description attribute which results in the following broken glue code

[Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute()]

"scenario names goes beyond 80 characters")]

A simple fix is to extend the regex to span multiple lines and remove the Description correctly. Although I don't know why the description has to be removed since it appears to compile just fine.

Anyway I added a pull request to resolve this. # #55

See #22 (comment).

MsTest categorizes Scenario Outlines as external, and not of the project in the test explorer. This is because we're not adding <generator allowDebugGeneratedFiles="true" /> to the specFlow section of app.config, see SpecFlowOSS/SpecFlow#275.

As per feedback on PR #7, it would be good to get the samples updated to run against the dnx451 work. Samples often suffer from chicken vs egg problems whereby updates to the core library need publishing to nuget before the samples can reference the latest changes.

An alternative approach is mentioned in the comments of PR #7 which I'll give a quick try. Otherwise I guess samples will have to wait until publishing each time.