Join GitHub today
SpecFlowSingleFileGenerator does not run for feature files contained in projects of type "9A19103F-16F7-4668-BE54-9A1E7A4F7556" #22
When using Specflow in a test project which uses any of the new project model elements introduced in VS2017 such as multi-targeting, nuget package references, .NET standard projects, .NET core projects, etc the SpecFlowSingleFileGenerator will not run feature files contained within the project.
Furthermore, due to a bug in visual studio, CodeClass2.Parts is not always populated for these projects. This was preventing detection of already existant step bindings which was in turn causing the syntax highlighting in the feature files to appear as if they did not have step bindings (purple).
There is still one outstanding issue I noted with these projects, which is that even with the two issues above fixed, you still must alter the .cs file containing the step bindings in order for the proper syntax highlighting to appear in the feature file.
More details about the changes below:
Is there a reason the new project system needs generators enabled? SpecFlow generators don't currently work properly with the new project system to begin with since the nuget package directory is no longer under the project's directory. Also, once SpecFlow does work with the new project system, it is my understanding that the preferred usage will be MSBuild based generation, not design time generation which means this will need to be removed anyways.
I would recommend that we don't enable this feature for the new csproj since there are no plans that I am aware of to make design time generation work with the new csproj system. If we remove this attribute, you can fairly easily add the MSBuild generation logic to your csproj file to have the same end result while not breaking future work (such as https://github.com/gasparnagy/SpecFlow.xUnitAdapter).
This change really messes up my project files anytime I add a feature file to my project. Perhaps we could not associate the .feature file extension with the generator, but still register the generator. Then in a targets file we could do something like (I haven't tested this):
<ItemGroup Condition="'$(SpecFlowMsBuildGenerationEnabled)' != 'true'"> <None Include="**\*.feature"> <Generator>SpecFlowSingleFileGenerator</Generator> </None> <Compile Update="**\*.feature.cs"> <DesignTime>True</DesignTime> <AutoGen>True</AutoGen> </Compile> </ItemGroup>
This would allow me to set the