New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SpecFlowSingleFileGenerator does not run for feature files contained in projects of type "9A19103F-16F7-4668-BE54-9A1E7A4F7556" #22

Merged
merged 1 commit into from Oct 20, 2017

Conversation

Projects
None yet
4 participants
@michaelmccord
Contributor

michaelmccord commented Sep 7, 2017

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:

  1. Due to the new project type included in visual studio 2017 that represents the new project model which has built in nuget references, multi-targeting, etc...must register for that project type so that the SpecFlowSingleFileGenerator runs on feature files contained in those projects.
    aspnet/Tooling#394 (comment)

  2. Due to a bug in visual studio, must fall back to using CodeClass2.Collection when CodeClass2.Parts is empty
    dotnet/roslyn#21074

mmccord
1) Due to the new project type included in visual studio 2017 that re…
…presents the new project model which has built in nuget references, multi-targeting, etc...must register for that project type so that the SpecFlowSingleFileGenerator runs on feature files contained in those projects.

aspnet/Tooling#394 (comment)
2) Due to a bug in visual studio, must fall back to using CodeClass2.Collection when CodeClass2.Parts is empty
dotnet/roslyn#21074
@michaelmccord

This comment has been minimized.

Show comment
Hide comment
@michaelmccord

michaelmccord Sep 7, 2017

Contributor

Note that this behavior could also be related to this:
dotnet/project-system#1821

Contributor

michaelmccord commented Sep 7, 2017

Note that this behavior could also be related to this:
dotnet/project-system#1821

@gasparnagy

This comment has been minimized.

Show comment
Hide comment
@gasparnagy

gasparnagy Oct 4, 2017

Collaborator

@SabotageAndi This looks good. Merge?

Collaborator

gasparnagy commented Oct 4, 2017

@SabotageAndi This looks good. Merge?

@SabotageAndi SabotageAndi merged commit bd72cdf into techtalk:master Oct 20, 2017

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@ChristopherHaws

This comment has been minimized.

Show comment
Hide comment
@ChristopherHaws

ChristopherHaws Jan 2, 2018

Contributor

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 SpecFlowMsBuildGenerationEnabled property in my project to disable the generators from getting run at design time.

Contributor

ChristopherHaws commented Jan 2, 2018

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 SpecFlowMsBuildGenerationEnabled property in my project to disable the generators from getting run at design time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment