-
Notifications
You must be signed in to change notification settings - Fork 754
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
Removing CodeBehind files from source #1362
Comments
Earlier versions of SpecFlow 3, we moved the code-behind generated files into a complete different folders. Additionally, Microsoft fixed a bug in VS, that the navigation from Test Explorer to the feature file works again (https://developercommunity.visualstudio.com/content/problem/267390/text-explorer-specflow-tests-goes-to-the-feature-c.html). For that, they need the code-behind files and they have to find it. Having the generated file in a complete separate folder will break this again. So we decided, that we stay with the code- behind generated files at the same folder as the feature file. I have to check, if we still care about the |
I've been using my own SpecFlow extension to generate codebehind at build time (as a workaround for no official .NET Core support). I had to put some work in to re-bind feature files to their source code due to how the project files were generated, but I haven't seen any other issues. The tests would link through to the feature file properly, despite the generated code being in the I can't seem to follow the link you provided at the moment; it looks like the server isn't taking requests right now. I'd be happy to work through any issues this might present. |
We saw problems, when we put the code-behind files into the |
Where my extension is limited to calling
The only case there is potentially problem is where a file is removed (by switching the branch) and the generated codebehind file still exists in the
|
As this has been open for two months without further input, let's assume there's limited interest in discussing this particular topic. Can we move forward in any way? This is a feature I would personally like to see in SpecFlow 3; getting generated files out of source control and out of the project structure is a generally good thing. If SpecFlow is moving to exclusively generate code as a build action instead of a design-time action, I think it is a cleaner solution to treat these as intermediary build files instead of source files (precisely what the \obj folder exists for). It makes the build process a lot easier to reason about when you aren't adding files to a directory structure during a build which will influence the next build. |
With SpecFlow 3 we are moving nearly exclusive to generate the code-behind files during build. Nearly only, because we need to be for at least some time backward compatible. I see no difference if we put the files under |
The difference is that when you put any files underneath the project root (but not in excluded locations like If you have seen issues when experimenting with using the
You can do this because you know all the inputs (the .feature files) and what should have been produced from them. Incidentally, this is also how you speed up incremental builds by specifying explicit inputs and outputs to the generation task. Another way to look at this is it being analogous to pure functions: When the build produces a side-effect of generating new source files in the project, it's no longer free of side-effects and is much harder to explain. |
Yeah, I forgot that you have to manually change the .gitignore file. From my experience, the normal globbing in the sdk-style projects include everything in the And yes, perhaps we did it wrong with our experiments. The whole MSBuild code is here: https://github.com/techtalk/SpecFlow/tree/master/SpecFlow.Tools.MsBuild.Generation/build We (@david1995 and me) have currently enough work to finish SpecFlow 3 for a final release, so at the moment we will not work on this. |
I'll work on a PR for the MSBuild code. |
Finally found time to spend on this, and doesn't look too hard if I take out support for generating the files within the project hierarchy. It's more challenging to support both ways of processing, due to the extra effort being spent in manipulating the @SabotageAndi, @david1995, do you think it's worth the additional complexity to continue supporting having the generated files live in the project structure? I don't object to putting in the effort; I just want to make sure it's effort well-spent. |
When switching branches works without problems and the Test Explorer navigation is still working, I don't care where the |
@SabotageAndi so not included code behind files '*.feature.cs' in solution explorer its a feature of SpecFlow v3? We notice in our projects after migration to SpecFlow v3 that newly added feature files doesn't had code behind file '*.feature.cs' (well the files are there after building the solution) but despite that everything is working fine. |
Hi @obstar, When using SpecFlow 3 inside a classic-style project (not SDK-style projects), you will not be able to see the Adding new Hope this helps. |
I have been sitting on a working set of MSBuild changes for this, but I've been struggling to create an automated test suite for this. Any suggestions on how to proceed? |
Ideally I think we need to cover the scenario where a project has been built and then a .feature file is removed, to make sure the incremental builds don't include anything from the old build. This should prove the solution works when source control operations cause feature files to be removed. I was thinking about creating a Is there a range of MSBuild support that has to be covered? |
The Don't forget we have a test project in the solution (https://github.com/techtalk/SpecFlow/tree/master/Tests/TechTalk.SpecFlow.MsBuildNetSdk.IntegrationTests) where you can test a lot of stuff also manually. |
@david1995 @SabotageAndi
and modyfing
into
also here https://specflow.org/2019/specflow-3-is-here/ |
If we want to run on just those two flavours of MSBuild (.NET Framework and .NET Core), it might be reasonable to create two test project runners and reference a shared suite of tests written as .a NET Standard library. Not something I've tried, but good in theory. I assume you'd rather see the tests written as features too? 😃 |
Finally, after a great deal of not-getting-stuff-done, here's a PR for your comments: |
Thanks to changes in the SpecFlow source, the new PR is a lot smaller and should be easier to discuss: |
One of the things I really liked about the .NET Core preview was the ability to treat the tool-generated files as build artefacts, not part of the source-controlled code. I've tried setting
SpecFlowCodeBehindOutputPath
in my test project, but it doesn't seem to be working.I get the warning
Followed by
I believe that removing
feature.cs
from the project structure is the superior position. I'd like to propose this should be the default position for SpecFlow 3, unless there are good reasons to keep this behaviour.I'd be happy to investigate the MSBuild changes needed to support this and put together a PR, if there's an appetite.
The text was updated successfully, but these errors were encountered: