Specflow: Feature File codebehinds not being generated in VS2017

[HowardvanRooijen]

Hi,

we have some new 4.5.2 projects using the new CSPROJ file format in VS2017 and we're having a few issues with feature files.

• adding a new feature file to a project doesn't add the SpecFlow custom tool property
• manually adding the custom tool property doesn't cause the code behind to be generated
• running "regenerate feature files" context menu action at the project level does nothing
• if I manually port a feature file + codebehind nesting doesn't work (I'm sure this is a VS issue)

Any Ideas?

Regards,

Howard

[pleveill]

On my side, I have the same. Even from command line I get this error.

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

The csproj file is from vs2017 and then start with

[SabotageAndi]

We currently do not support the new project system.
You could try our MSBuild integration (http://specflow.org/documentation/Generate-Tests-from-MsBuild/) for generating the code behind files. But I am not sure that this works. I didn't have time yet to test this.

[HowardvanRooijen]

Thanks for the workaround - is supporting the new project system in your backlog / something you're actively working on - or do you need some help to make it happen?

[SabotageAndi]

@HowardvanRooijen Here you find the "backlog" for .NET Core: https://github.com/techtalk/SpecFlow/projects/2

[rhwilburn]

Does the work around mentioned work for anyone? It doesn't for me.

I would think that the net framework side of the .net core projects could be an easier first step in fixing this, then working .net core targeting netstandard. This would also enable fairly easy work arounds for those not on linux or mac.

Specflow.NetCore doesn't work either as that expects a project.json file and even if you supply one, it doesnt generate the files

[SabotageAndi]

@rhwilburn No, it does not. We found this out, when we worked on #649.
With PR #837 this should work now, but we didn't tried it out yet.

[SabotageAndi]

The latest prerelease does not depend anymore on MSBuild to read the project file and can handle also the new csproj files in a limited scope.
@HowardvanRooijen could you give it a try?

[HowardvanRooijen]

Fantastic. I'll give it a go (or get someone else in the team to try it out, as I'm on holiday this week). Thanks for the great work. What do you now use for processing the CSPROJ files?

[mwadams]

@SabotageAndi - Do we just need to use the latest prerelease nuget, or is there an updated VSIX?

[SabotageAndi]

@HowardvanRooijen We first tried to use Roslyn- Workspaces, but this is excuting some compiler. So we ended up with parsing it as XML.
PRs are https://github.com/techtalk/SpecFlow/pull/837 and https://github.com/techtalk/SpecFlow/pull/843.

Additional info: With the new csprojs, it looks like, our current target file is not working.
I stumbled upon this at the work to migrate SpecFlow to it.
Please have a look at the adapted version: https://github.com/techtalk/SpecFlow/blob/DotNetCore/TechTalk.SpecFlow.Tools/MsBuild/TechTalk.SpecFlow.NewCSProj.targets
and the usage of it: https://github.com/techtalk/SpecFlow/blob/DotNetCore/Tests/TechTalk.SpecFlow.Specs/TechTalk.SpecFlow.Specs.csproj

[SabotageAndi]

@mwadams You need only the latest prerelease nuget from nuget.org: https://www.nuget.org/packages/SpecFlow/2.2.0-preview20170523

[mwadams]

Ah - OK. So, yes, against a new csproj it wasn't working. I'll try that workaround above.

[mwadams]

@SabotageAndi Yup - that worked. I now have a generated feature file in my solution.

Am I expecting the VS2017 feature file editor to locate my step definitions and provide the usual F12 support?

[mwadams]

Ah - hang on. I was using XUnit. And the Feature file has generated me NUnit output...

[mwadams]

One quick switch to NUnit later, and a I have a net47 new-style CSPROJ referencing NetStandard1.6 assemblies and some generated feature files that builds.

However, I still have no step definition discovery in the editor, and the NUnit3 test runner is not discovering any of the tests.

[SabotageAndi]

Do you have XUnit configured in the app.config? NUnit is the default value.

[mwadams]

@SabotageAndi : No - it was a slip of the nuget... I meant to use NUnit #doh

[SabotageAndi]

Stef definition discovery is made by the VS Extension. Could be, that this is not working with the new project system. I didn't checked this.
Do you have the NUnit3TestAdapter package added to your project? This has the test adapter for the Test explorer, so that it can display NUnit tests.

[robbaman]

I'm a bit confused, has this issue been resolved already? I'm using v2.2.1 of the SpecFlow NuGet package and v2017.1.6 but in VS2017 using a test project with the new project format doesn't generate the code behind files for my .feature files.

[SabotageAndi]

@robbaman There is only support for the new project system in the MSBuild integration (http://specflow.org/documentation/Generate-Tests-from-MsBuild/). And this is limited.

[robbaman]

Ah I see, this solution kind of feels like a hack at the moment. The instructions on the page don't seem to work exactly as provided (for instance my packages are apparently stored in a shared .nuget folder instead of in the ..\packages folder.

Is there any ETA on when (if ever) the VS2017 plugin will simply work again with the custom tool?

Thanks for the quick reply btw :)

[SabotageAndi]

@robbaman No, no ETA. Probably never, as when we are finished with .NET Core support (https://github.com/techtalk/SpecFlow/projects/2) the code-behind files will be gone.

[robbaman]

I may have missed it, but is there any documentation on the recommended workflow in the new project system.

I mean, if adding the VS addon and the NuGet package alone does not work, what other steps are required to make it work.

I suppose I can just use the old project system for my test projects for now, but Id prefer to use the latest and greatest...

[SabotageAndi]

No, there isn't any documentation for it.
I have it working in a project, by using the MSBuild integration and some changes to the target files.

I will have a look if somebody can document this. But this could take some time. In the meantime I would stick to the old project system.

[robbaman]

Alright, thanks for the quick response.

[sandermvanvliet]

I’ve got a temporary solution to get this to work for at-build code generation. You can read about it here, note that it doesn’t “fix” the on-save code generation though

[SabotageAndi]

I have created also an example for that, but it is not yet documented: https://github.com/techtalk/SpecFlow.Plus.Examples/blob/master/NewCSProjFormat/SpecFlowNewCSProjFormat/SpecFlowNewCSProjFormat.csproj

@sandermvanvliet You can use the normal Sdk="Microsoft.NET.Sdk". You don't need to split into two imports.

[kyurkchyan]

@SabotageAndi Thanks for the example. I have one problem both in this project also in mine. If I generate the step definitions in the same folder as the feature file is, specflow won't recognize that all steps are bound, and the feature fill would always be purple. As soon as I move it to separate folder, everything works just fine. Any ideas why would that happen?

[SabotageAndi]

@kyurkchyan We did nothing to support syntax highlighting with the new project format. This would be part of the Visual Studio Integration.
So it is more luck if something works.

[alexanderwilliamson]

Looking forward to a fix when SpecFlow generation works automagically in a net462 VS2017 solution.

[Gonnagle]

I was also able to get the workaround provided by @SabotageAndi to work with a project using Paket with minor modifications (package folders don't include version numbers in this case). Here is a gist of a complete example:

https://gist.github.com/Gonnagle/98de2a3531185b677d248f90926a174a

[SabotageAndi]

I think with this PR: https://github.com/techtalk/SpecFlow.VisualStudio/pull/22 the custom tool is now set for feature files in the new projects.
The version which includes this PR is already published to the marketplace. It has version 2017.1.10.

@HowardvanRooijen could you check this?

@Gonnagle: could you create an issue with the issues you have with paket and "stock" SpecFlow, so we can fix this once and for all.

[SabotageAndi]

@3686 What do you mean with this comment: https://github.com/techtalk/SpecFlow/issues/820#issuecomment-345553389
Full framework was always supported. Please open a separate issue if you have problems.

[Gonnagle]

@SabotageAndi don't think it essentially differs from the issue here. I've prepared a repro here (the SpecFlowNewProject): https://github.com/Gonnagle/paket-tests/tree/specflow-issue-820-new-csproj-feature-file-generation

Broken state: https://github.com/Gonnagle/paket-tests/releases/tag/specflow-issue-820-broken
Workaround applied (if you run rebuild on this you should end up to the state of the latest commit): https://github.com/Gonnagle/paket-tests/releases/tag/specflow-issue-820-workaround

I should have the latest version of SpecFlow for Visual Studio 2017 (shows 2017.1.10 on "Extensions and Updates")

If really wanted I can still create a separate issue (almost did as requested, but felt that descriptive name would be "_Feature files not being generated with the new csproj style_" which felt a bit too close to this one...).

[phatcher]

Sorry that %userdata% should be $(UserProfile)

[SabotageAndi]

@Gonnagle I think these are separate issues.
This one was originally for the new csproj format.
Your issue is with paket. AFAIK paket stores the NuGet packages not in the local package folder.
I think paket + SpecFlow also doesn't work with the old project format.

[phatcher]

Sorry my previous comment went away....

My version of the code looks like this...

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <!--
  <ItemGroup>
    <Compile Update="SpecFlowFeature1.feature.cs">
      <DesignTime>True</DesignTime>
      <AutoGen>True</AutoGen>
      <DependentUpon>SpecFlowFeature1.feature</DependentUpon>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <None Update="SpecFlowFeature1.feature">
      <Generator>SpecFlowSingleFileGenerator</Generator>
      <LastGenOutput>SpecFlowFeature1.feature.cs</LastGenOutput>
    </None>
  </ItemGroup>
  -->
  <!-- Workaround to get SpecFlow code generation work with new csproj https://github.com/techtalk/SpecFlow/issues/820#issuecomment-342777180 -->
  <PropertyGroup>
    <SpecFlowPath>$(UserProfile)\.nuget\packages\SpecFlow\2.2.1\tools</SpecFlowPath>
    <SpecFlowTasksPath>$(SpecFlowPath)\specflow.exe</SpecFlowTasksPath>
  </PropertyGroup>
  <Import Project="$(SpecFlowPath)\TechTalk.SpecFlow.tasks" Condition="Exists('$(SpecFlowPath)\TechTalk.SpecFlow.tasks')" />
  <Import Project="$(SpecFlowPath)\TechTalk.SpecFlow.targets" Condition="Exists('$(SpecFlowPath)\TechTalk.SpecFlow.targets')" />

  <Target Name="PreBuild" BeforeTargets="PreBuildEvent">
    <CallTarget Targets="GenerateSpecFlowCodeBehinds" />
  </Target>

  <Target Name="GenerateSpecFlowCodeBehinds">
    <ItemGroup>
      <FilesToDelete Include="Features\**\*.feature.cs" />
    </ItemGroup>
    <Delete Files="@(FilesToDelete)" />

    <CallTarget Targets="UpdateFeatureFilesInProject"></CallTarget>
  </Target>
</Project>

This works both locally and on the build server as MsBuild 15 uses the user profile directory for the local nuget cache.

It does couple to the version of the SpecFlow package, but using the variable I've reduced that to a single line change, I also limit the C# files it deletes so as to avoid any step definitions in the same directories

I remove the auto-generation as I still have issues of it using the SpecFlow 1.9 generator occasionally.

[Gonnagle]

@SabotageAndi in the repo I provided there is another project using paket and the old project format whitout any issues that I've noticed. I've also used SpecFlow+paket successfully in other projects. Paket does still place nugets in "packages" folder, it just doesn't add the version in the path (normally no multiple versions of same nuget in one solution). So to get your workaround to work I just had to adjust the paths a bit.

[malcolmarobertson]

I had this problem and solved it by right-clicking on the feature file and selecting "run custom tool".

[Friendbot2k]

@robbaman No, no ETA. Probably never, as when we are finished with .NET Core support (https://github.com/techtalk/SpecFlow/projects/2) the code-behind files will be gone.

Just to clarify, when you finish the .NET Core support this issue will likely be fixed because the code-behind files will be gone?

[SabotageAndi]

@Friendbot2k We will still have code- behind files in .NET Core. We changed our minds.

[SabotageAndi]

As with VS2017.1.12 we set the Custom Tool also in the new project format (PR: https://github.com/techtalk/SpecFlow.VisualStudio/pull/22).
So I am closing this issue.

About the paket issues: please open a separate issue for that.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.