Skip to content

refactor: anchor build output paths on the repo instead of $(SolutionDir) - #676

Merged
Hirogen merged 1 commit into
Developmentfrom
refactor/normalize-output-paths
Jul 28, 2026
Merged

refactor: anchor build output paths on the repo instead of $(SolutionDir)#676
Hirogen merged 1 commit into
Developmentfrom
refactor/normalize-output-paths

Conversation

@Hirogen

@Hirogen Hirogen commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

refactor: anchor build output paths on the repo instead of $(SolutionDir)

Closes the "TODO: Normalize this across solution" on the commented-out OutputPath in Directory.Build.props.

$(SolutionDir) is only defined when MSBuild is driven by the .sln. Fourteen projects spelled their output as "$(SolutionDir)..\bin...", so under a solution build that resolved to bin, but a lone dotnet build Foo.csproj resolved the same text relative to the project and quietly wrote to src\bin\ instead - while the Nuke targets, the installer file list and the CI artifact all look in bin. Nothing failed; the single-project build just stopped agreeing with everything else. It cost real time during the plugin-hash work, where a lone build looked reproducible only because the file being hashed was a stale leftover.

Anchor the paths on $(MSBuildThisFileDirectory) instead and name them once:

LogExpertBinRoot / LogExpertBinDirectory / LogExpertPluginsDirectory /
LogExpertPluginsX86Directory / LogExpertDocsDirectory

Configuration has to be defaulted alongside them: Directory.Build.props is imported before the SDK defaults it, and an empty value silently collapses bin\Debug\ to bin. The condition leaves an explicit -c or a solution build untouched.

Also folded in:

  • the two DocumentationFile paths, which had the same $(SolutionDir) defect
  • four test projects that hand-wrote bin$(Configuration), which is exactly the SDK default once AppendTargetFrameworkToOutputPath=false
  • PluginHashGenerator.targets now reads the shared properties rather than re-deriving the plugins directory, so the two cannot drift apart

The $(SolutionDir) use left in src/SDK/ is deliberate: those samples are built from their own solution by plugin authors, not by ours.

Output layout is unchanged - verified byte-for-byte against a pre-change snapshot: same 18 directories under bin/Release, same 65 files at its root, 19 plugins, 10 pluginsx86, both XMLs in bin/Docs. Lone builds of AutoColumnizer, SftpFileSystemx86, ColumnizerLib and LogExpert now land there too and no longer create src\bin. Plugin hash table still 21 entries in both configurations, all matching the shipped binaries.

…Dir)

Closes the "TODO: Normalize this across solution" on the commented-out
OutputPath in Directory.Build.props.

$(SolutionDir) is only defined when MSBuild is driven by the .sln. Fourteen
projects spelled their output as "$(SolutionDir)..\bin\...", so under a solution
build that resolved to bin\, but a lone `dotnet build Foo.csproj` resolved the
same text relative to the project and quietly wrote to src\bin\ instead - while
the Nuke targets, the installer file list and the CI artifact all look in bin\.
Nothing failed; the single-project build just stopped agreeing with everything
else. It cost real time during the plugin-hash work, where a lone build looked
reproducible only because the file being hashed was a stale leftover.

Anchor the paths on $(MSBuildThisFileDirectory) instead and name them once:

  LogExpertBinRoot / LogExpertBinDirectory / LogExpertPluginsDirectory /
  LogExpertPluginsX86Directory / LogExpertDocsDirectory

Configuration has to be defaulted alongside them: Directory.Build.props is
imported before the SDK defaults it, and an empty value silently collapses
bin\Debug\ to bin\. The condition leaves an explicit -c or a solution build
untouched.

Also folded in:
- the two DocumentationFile paths, which had the same $(SolutionDir) defect
- four test projects that hand-wrote <OutputPath>bin\$(Configuration)</OutputPath>,
  which is exactly the SDK default once AppendTargetFrameworkToOutputPath=false
- PluginHashGenerator.targets now reads the shared properties rather than
  re-deriving the plugins directory, so the two cannot drift apart

The $(SolutionDir) use left in src/SDK/ is deliberate: those samples are built
from their own solution by plugin authors, not by ours.

Output layout is unchanged - verified byte-for-byte against a pre-change
snapshot: same 18 directories under bin/Release, same 65 files at its root,
19 plugins, 10 pluginsx86, both XMLs in bin/Docs. Lone builds of AutoColumnizer,
SftpFileSystemx86, ColumnizerLib and LogExpert now land there too and no longer
create src\bin. Plugin hash table still 21 entries in both configurations, all
matching the shipped binaries. Full suite: 1491 passed, 7 skipped, 0 failed.
@Hirogen
Hirogen merged commit 12566d9 into Development Jul 28, 2026
3 checks passed
@Hirogen
Hirogen deleted the refactor/normalize-output-paths branch July 28, 2026 13:02
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.

1 participant