The code-behind file generation is invoked even if the feature files were not changed

[gasparnagy]

When you invoke dotnet build multiple times, you would expect that the code-behind file generation is not invoked. Maybe it is surprising but the generation task is still invoked for all feature files currently.

> dotnet build
[...]
> dotnet build <-- this should not trigger the generation, but it does

It is a bit hard to prove this, but if you add a line

Debug.WriteLine(outputPath, "GEN");

to

Reqnroll/Reqnroll.Tools.MsBuild.Generation/CodeBehindWriter.cs

Line 21 in df77e3b

{

and open a DebugView while running the dotnet build command, it shows each feature file.

Note 1: Although the generator is invoked, no actual file write is happening, because the CodeBehindWriter class compares the file to be written out with the actual content and it only writes if they are different. This seems to be counter-intuitive, but we have measured it and it provides better performance this way, even on SSD drives.

Note 2: There is a TestUpToDateChecker class in the codebase that performs up-to-date checks based on some heuristics, but that functionality is NOT USED, because the GenerationSettings.CheckUpToDate is never set to true, except in tests. So that is actually a dead code, we should remove it once we find a good consensus.

Note 3: When you build from Visual Studio, it uses a slightly different build mechanism and if the project was not changed the project build is not even invoked. But once it is invoked, maybe because of an unrelated change, it will invoke the generator even for the unchanged feature files. So to diagnose this issue it is easier to use dotnet build.

When I mentioned this to @Code-Grump on another thread, he made the following comment:

If you're doing the output check right, MSBuild will only execute the target when it detects the file is missing or out of date.
MSBuild's stale check is very simple:

• Of the input and output files for a target:
• Are any of the output files missing?
• Are any of the inputs newer than the output files according to their last write timestamps?

It's crude, but it's how all the build optimisations are done. We should be able to do the exact same thing [...].

Regrettably, our current MSBuild implementation has absolutely no inputs or outputs declared on the target, so we're not taking advantage of incremental builds like we could.

And a little bit of history and background:

A concrete code-behind file depends on:

• The feature-file content
• The projects default namespace
• The project programming language (C# / VB)
• The default Gherkin language configuration in reqnroll.json
• The generator settings in reqnroll.json

Obviously the most important input is the feature-file content. The others change very rarely, people would probably OK with invoking a re-build (or clean & build) in this case.

Initially we used a simple timestamp-based configuration, similar to what @Code-Grump mentioned, that worked for most of the causes, but caused trouble in the following (not that rare) situation.

Branch Change Situation:

• You work on the main branch, updating a feature file with "change X" and build. The code-behind will be re-generated and it's timestamp will be newer then the feature file timestamp
• You decide to make a code review of the stuff of someone else who did changes yesterday: you switch back to the feature1 branch. This will restore the feature file to it's previous version, but does not modify the code-behind file, because that is not in the git repo.
• Update since initial post:
  • This is not a problem with git, as git will set the timestamp to "now" even if you checkout an old branch, so the feature file timestamp of will be newer than the code behind timestamp.
  • I don't remember, but maybe some other source-control providers (maybe SVN?) were resetting the last write time to an older last write time that has confused the up-to-date check.

Because of this situation, we finally decided to disable this up-to-date checking mechanism, this is why GenerationSettings.CheckUpToDate is never set to true as mentioned above. We kept the basic write-only-if-change check, because it was still beneficial, but obviously that is not very effective, because all the calculations and parsing has to be made still before we can decide that it is up-to-date.

Seeing this now, because ~everyone uses git, this disabling seems to be unnecessary and we could enable it again.

End of history.

I would like to think it over once more if we could improve the current behavior, especially with the built-in optimization mechanism from MsBuild. But to move on with that, I have a few questions:

• If we would apply the input/output options of the MsBuild task, how would that behave for the mentioned "Branch Change Situation"? And if it does not handle correctly the "Branch Change Situation", how other projects/tools overcome the same issue?
• Is the MsBuild input/output optimization works only if the task would be invoked for each file individually or does it also work if we invoke the task only once for all feature file that requires re-generation. And if it works, how would it select that from the input list which ones need to be regenerated and which not?

[Code-Grump]

If we would apply the input/output options of the MsBuild task, how would that behave for the mentioned "Branch Change Situation"? And if it does not handle correctly the "Branch Change Situation", how other projects/tools overcome the same issue?

When you change branch, files are updated. Input newer than output causes targets to be executed.

Is the MsBuild input/output optimization works only if the task would be invoked for each file individually or does it also work if we invoke the task only once for all feature file that requires re-generation. And if it works, how would it select that from the input list which ones need to be regenerated and which not?

MSBuild is actually kind-of fantastic in this department. When you declare inputs and map them to outputs, MSBuild will reduce the input batch to just the dirty files so your target's logic is completely unchanged, but will only run for the subset of inputs that need it.

[Code-Grump]

I've put together a PR for what it takes to add incremental support via MSBuild's Input and Output properties. Happy to answer implementation questions there. #793

[gasparnagy]

Great. I will try right now!

[gasparnagy]

That PR does not work for me. ☹️ The generator is still invoked. I'll make a comment to the PR.

[gasparnagy]

If we would apply the input/output options of the MsBuild task, how would that behave for the mentioned "Branch Change Situation"? And if it does not handle correctly the "Branch Change Situation", how other projects/tools overcome the same issue?

When you change branch, files are updated. Input newer than output causes targets to be executed.

OK. Thanks for the clarification. I have also double checked and git sets the last write time to "now" even if you switch back to an old branch, so the timestamp-based up-to-date check should be effective. Probably it was another source control provider (SVN?) that we had this problem, but it is certainly not a problem with git. I will update the intro comment.