Skip to content

Fix CustomPlugin and SpecflowCompatiblity.ReqnrollPlugin builds by adjusting pack#1058

Open
obligaron wants to merge 3 commits intomainfrom
fix/buildproblem
Open

Fix CustomPlugin and SpecflowCompatiblity.ReqnrollPlugin builds by adjusting pack#1058
obligaron wants to merge 3 commits intomainfrom
fix/buildproblem

Conversation

@obligaron
Copy link
Contributor

🤔 What's changed?

  • Reqnroll.CustomPlugin uses IncludeBuildOutput to avoid processing empty BuildOutput.
  • Reqnroll.SpecFlowCompatibility.ReqnrollPlugin sets IsPackable to false, because it's included in Reqnroll.SpecFlowCompatibility (part of lib nuget folder)

⚡️ What's your motivation?

Fixes #1057

🏷️ What kind of change is this?

  • 🐛 Bug fix (non-breaking change which fixes a defect)

♻️ Anything particular you want feedback on?

I checked that the generated nuget packages have the same content as the last published in nuget but it would be good if someone else looks again.


This text was originally taken from the template of the Cucumber project, then edited by hand. You can modify the template here.


system-tests-windows:
runs-on: windows-latest
runs-on: windows-2025-vs2026
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@obligaron how did you determine that this needs to be changed? I have another PR that is giving the same failures during build on GitHub. I had no idea even where to begin. Trying to learn something new.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im also curious why this is needed :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test output showed:

D:\testrundata\RR\Rf7c50b2d\Sfc8894f3\DefaultTestProject\DefaultTestProject.csproj : error : Could not resolve SDK "Microsoft.NET.Sdk". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
D:\testrundata\RR\Rf7c50b2d\Sfc8894f3\DefaultTestProject\DefaultTestProject.csproj : error :   Version 10.0.201 of the .NET SDK requires at least version 18.0.0 of MSBuild. The current available version of MSBuild is 17.14.40.60911. Change the .NET SDK specified in global.json to an older version that requires the MSBuild version currently available.
D:\testrundata\RR\Rf7c50b2d\Sfc8894f3\DefaultTestProject\DefaultTestProject.csproj : error :   The NuGetSdkResolver did not resolve this SDK because there was no version specified in the project or global.json.
D:\testrundata\RR\Rf7c50b2d\Sfc8894f3\DefaultTestProject\DefaultTestProject.csproj : error :   MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.Sdk" because directory "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\Sdk" did not exist.
D:\testrundata\RR\Rf7c50b2d\Sfc8894f3\DefaultTestProject\DefaultTestProject.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found., but found False.

The interesting parts was

  • Version 10.0.201 of the .NET SDK requires at least version 18.0.0 of MSBuild.
    This means he found the .NET SDK but the MSBuild was too old.
  • MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.NET.Sdk" because directory "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\Sdk" did not exist.
    Showed that VS2022 was used and VS2022 doesn't support .NET 10.

After that I first thought that VS2022 was used instead of VS2026 was used. I could reproduce this locally when both Visual Studio versions are installed. So I ensured VS2026 was used (if available) instead of VS2022 (second commit).
This still doesn't work in CI, because the windows-latest runner only contains VS2022. So I switched to windows-2025-vs2026 image (third commit).

What I still can't figure out is why this worked before. Perhaps some changes happened in the GitHub runner?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only happens in the tests where we don't build our generated test projects via dotnet build but instead use msbuild directly.

@clrudolphi
Copy link
Contributor

And what caused nuget packing to fail for those two plugins, now, compared to what we've been doing since the packing approach was (recently) updated? It seems like this came out of nowhere.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reqnroll Build Fails when Packaging CustomPlugin and SpecFlowCompatibilityPlugin

3 participants