MsBuild Targets such as ReqnrollFeatureFiles and ReqnrollObsoleteCodeBehindFiles: Can't find much about them.

[dqwork]

Hey Reqnroll team!

First things first... Thank you! Keeping the project formally known as SpecFlow alive! It is really appreciated and the migration process has been simple so far. Over 10,000 tests and took me about ~1 hour.

One thing I couldn't find much information on was SpecFlowFeatureFiles and SpecFlowObsoleteCodeBehindFiles MSBuild Targets and their new Reqnroll versions ReqnrollFeatureFiles and ReqnrollObsoleteCodeBehindFiles.

I just took a stab at those ReqnRoll names and they seemed to work which was nice. But so far I can't actually find any Docs on setting up having the 'code behind' files generated from the build process. (For example here's the specflow docs on it https://docs.specflow.org/projects/specflow/en/latest/Tools/Generate-Tests-From-MsBuild.html)

the fact the MSBuild targets still exist implies they are supported, but wondered if there any docs about it? If not I think they would be a good addition

Thanks again!

[ajeckmans]

MsBuild is something of a quite complex beast to tackle :)

MsBuild targets are 'supported' in the sense that the reqnroll infra is built around it. If you're familiar with how MsBuild works you should be able to read https://github.com/reqnroll/Reqnroll/blob/main/Reqnroll.Tools.MsBuild.Generation/build/Reqnroll.Tools.MsBuild.Generation.props and get a grasp on how everything ties together.

As for any change from specflow to rider, I expect there to be little to none and for the reqnroll package to be a drop in replacement.

I do wonder why you'd need to go to the internals of reqnroll as this is all handled when you use one of the unit-test provider packages of reqnroll (like also suggested on that specflow documentation page).

[dqwork]

We have csproj files that uses those Targets, so they came up when I grepped our code base for Specflow.

I'm migrating a codebase that I didn't build this part of so can't comment to much on the why - we have some 'clever' pseudo projects that allows us to breakdown our 10,000+ tests in a around 10+ projects that means if you change a single feature file, you don't have to regenerate all of them, just the project that changed.

For example here is the csproj file for one of this projects

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="$(SolutionDir)\<redacted_Path_1>.props" />
  <ItemGroup>
    <Compile Remove="<redacted_Path_2>\**" />
    <Compile Remove="<redacted_Path_3>\**" />
    <EmbeddedResource Remove="<redacted_Path_2>\**" />
    <EmbeddedResource Remove="<redacted_Path_3>\**" />
    <None Remove="<redacted_Path_2>\**" />
    <None Remove="<redacted_Path_3>\**" />
    <ReqnrollFeatureFiles Remove="<redacted_Path_2>\**" />
    <ReqnrollFeatureFiles Remove="<redacted_Path_3>\**" />
    <ReqnrollObsoleteCodeBehindFiles Remove="<redacted_Path_2>\**" />
    <ReqnrollObsoleteCodeBehindFiles Remove="<redacted_Path_3>\**" />
  </ItemGroup>
</Project>