Every time a Visual Studio user would open the Halibut solution, VS would alter it.
If the unsuspecting VS user was not paying attention, this change would often make its way into a PR, and the build server would no longer compile. Often leaving the poor VS developer confused about what they did wrong.
Results
Before
VS would add the following configuration lines when the solution was opened:
When the altered solution was built with Nuke (what we do on the build server), it would add the following warning at the start:
11:10:28 [WRN] Solution C:\Dev\Halibut\source\Halibut.sln has active build configurations for the build project.
Either enable SuppressBuildProjectCheck on Build.Solution or remove the following entries from the solution file:
- {55223D02-0CE9-4325-9A4D-5E88A544B633}.Debug|Any CPU.Build.0 = Debug|Any CPU
- {55223D02-0CE9-4325-9A4D-5E88A544B633}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
- {55223D02-0CE9-4325-9A4D-5E88A544B633}.Debug|x86.Build.0 = Debug|Any CPU
- {55223D02-0CE9-4325-9A4D-5E88A544B633}.Release|Any CPU.Build.0 = Release|Any CPU
- {55223D02-0CE9-4325-9A4D-5E88A544B633}.Release|Mixed Platforms.Build.0 = Release|Any CPU
- {55223D02-0CE9-4325-9A4D-5E88A544B633}.Release|x86.Build.0 = Release|Any CPU
And we would see several warnings like this during the build:
11:10:33 [WRN] C:\Program Files\dotnet\sdk\6.0.414\Microsoft.Common.CurrentVersion.targets(5097,5): warning MSB3026: Could not copy "C:\Dev\Halibut\build\obj\Debug\apphost.exe" to "bin\Debug\_build.exe". Beginning retry 1 in 1000ms. The process cannot access the file 'C:\Dev\Halibut\build\bin\Debug\_build.exe' because it is being used by another process. The file is locked by: "_build (31280)" [C:\Dev\Halibut\build\_build.csproj]
Resulting in 2 build errors and this summary
After
After VS altered the solution, the Configuration Manager showed that the _build.csproj was configured to be built.
This is not what we should be doing (verified by Octopus Server, as that also does not build _build.csproj).
When setup correctly, some lines were added to the solution to ensure _build.csproj is no longer built by VS and Nuke.
But with these lines, VS no longer tries to manipulate the solution.
The Nuke output is now identical to the 'untouched' version.
How to review this PR
Quality :heavy_check_mark:
Pre-requisites
[ ] I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
[ ] I have considered informing or consulting the right people, according to the ownership map.
[ ] I have considered appropriate testing for my change.
[sc-62554]
Background
Every time a Visual Studio user would open the Halibut solution, VS would alter it.
If the unsuspecting VS user was not paying attention, this change would often make its way into a PR, and the build server would no longer compile. Often leaving the poor VS developer confused about what they did wrong.
Results
Before
VS would add the following configuration lines when the solution was opened:
When the altered solution was built with Nuke (what we do on the build server), it would add the following warning at the start:
And we would see several warnings like this during the build:
Resulting in 2 build errors and this summary
After
After VS altered the solution, the Configuration Manager showed that the
_build.csproj
was configured to be built.This is not what we should be doing (verified by Octopus Server, as that also does not build
_build.csproj
).When setup correctly, some lines were added to the solution to ensure
_build.csproj
is no longer built by VS and Nuke.But with these lines, VS no longer tries to manipulate the solution.
The Nuke output is now identical to the 'untouched' version.
How to review this PR
Quality :heavy_check_mark:
Pre-requisites