Specflow: Discussion: How to stop Visual Studio from adding a CustomTool when adding a new feature file in SDK-Style projects

[SabotageAndi]

From the beginning of SpecFlow, we were using a CustomTool to generate the code- behind files for the feature file.
It worked well, but if you want use generate the code-behind files at compile/build time, you had to do additional steps everytime to add a new file (remove the custom tool).

With the sdk-style projects this is getting now more and more worse.
This happens when you add a new feature file to a sdk-style project with SpecFlow 3:

It removes the new item from our MSBuild ItemGroup (for generating the code-behind files) and add it to the None- ItemGroup and the code-behind file to the Compile- Itemgroup.
Everything that would be done by the SpecFlow.Tools.MSBuild.Generation package is reversed.

We believe the reason for this is the custom- tool registration.
Relevant code is here:
https://github.com/techtalk/SpecFlow.VisualStudio/blob/master/VsIntegration/SingleFileGenerator/SpecFlowSingleFileGenerator.cs#L24
https://github.com/techtalk/SpecFlow.VisualStudio/blob/master/VsIntegration/SingleFileGenerator/CodeGeneratorRegistrationWithFileExtensionAttribute.cs

Sadly the custom tool registration is done by programming language and not by project type. And if you remove the registration, it can't be used at all.
So removing the registration for C# would force everybody to use the SpecFlow.Tools.MSBuild.Generation nuget package.
This would be a major breaking change and so we don't want to do it.

What we would need is a way, to better decide when the custom tool is added automatically.
Does anybody have an idea how to do this?

[BasHamer]

Can you generate a near blank file that lets people know what the real file is generated at compile time? As long as the file is static it solves the issue of a regeneration where you are waiting as your IDE checks out each file individually. That way people can remove the registration when completely cutover; effectively creating a "compatibility-mode" for now.

[SabotageAndi]

The file that is generated by the CustomTool and by the MSBuild package is the same. So you when you save the file in the editor, it would override the file with nothing. Then you compile and it is again replaced with the real code. I am not sure if this is better.

[BasHamer]

Can you do the generation in a sperate folder for the compile time generation? (similar to typescript to javascript in angular sites?) It seems like we would want to ignore these files from check-in anyway if they are compile generated.

[SabotageAndi]

Generating the files in a different folder makes other problems. We tried it.

My current best "idea" is to extract the CustomTool in a additional extension that people have to install to get this functionality. But I am not happy with this, because this breaks people also until they notice they have to install something additionally.

[BasHamer]

can you elaborate on other problems? The Visual Studio integration does not look like you have enough wiggle room to stop the process from triggering conditionally and it is probably reasonable to assume visual studio won't change.

So given that your tool will run (for now), how can we limit the undesirable behavior.

[SabotageAndi]

One problem is, that it would break a finally fixed problem. It is this: https://developercommunity.visualstudio.com/content/problem/267390/text-explorer-specflow-tests-goes-to-the-feature-c.html
The way how it was fixed needs that the feature.cs is in the same folder as the feature file.

Additionally it makes it more difficult to check if there are changes that needs to regenerate the code-behind files.

[BasHamer]

Another idea;

Looking at some other code generation solutions (scripty in this case) would it make sense to separate out the responsibility for code generation, and create an artifact file in the folder with the features that would nest the features underneath it? It feels a bit wonky, but part of me wonders if seperating the responsibilities out might help a lot. Again that is close to the double plugin scenario as well.

[SamJongenelen]

Could a workaround (perhaps on the right click context menu?) that fixes/cleans the csproj be made?

[SabotageAndi]

Some update to this:
I am trying to make the CustomTool configurable, so you can turn the adding of the CustomTool on and off.

[LeGaryGary]

Hello, is there any progress update on this as it is causing some irritation in my team when adding new features, otherwise specflow 3 is working really well for us.

[SabotageAndi]

We are still working on it. It's not that easy to fix it.

PR for enable/disable of custom tool: https://github.com/techtalk/SpecFlow.VisualStudio/pull/45
Issue about the ItemGroup changes: https://github.com/dotnet/project-system/issues/4483

The part of VS that we need is not that well documented.

[SabotageAndi]

Thanks to @dasMulli this issue is now fixed with commit https://github.com/techtalk/SpecFlow/commit/b52d415bc1ea9afc8e641c4fbb0c89a3a4d4e416

[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.