Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/).

## [Unreleased]

## [3.2.2] - 2026-09-02

### Added

- [SIL.BuildTasks] Added MakeWixForDirTree.ConsolidatedGuidFile (optional param) naming a single file to hold the GUIDs for the whole tree, instead of a `.guidsForInstaller.xml` in every directory. Any per-directory files still present under RootDirectory are merged into it, so existing GUIDs carry over unchanged and installed components keep their identity; delete them from version control once the merged file has been committed. With CheckOnly the merge happens in memory only and the task reports an error naming the files whose GUIDs are not yet in the consolidated file.
Expand All @@ -24,6 +26,17 @@ and this project adheres to [Semantic Versioning](http://semver.org/).

- [SIL.BuildTasks] Fixed MakeWixForDirTree.CheckOnly deleting the previously generated wxs file. A check-only run outputs nothing, so it now leaves the existing file alone.

### Security

- Reverted SIL.Core from 17.0.0 to 9.0.0. 17.0.0's dependency on Mono.Unix
(which has never had a stable, non-prerelease NuGet release) broke restore
for consumers using classic `nuget.exe install` without `-Prerelease`.
This reintroduces a build-time-only dependency on Newtonsoft.Json 11.0.1
(GHSA-5crp-9r3c-p9vr, DoS via deeply-nested JSON) until libpalaso resolves
the Mono.Unix situation upstream — SIL.BuildTasks never processes
untrusted JSON and isn't shipped in consumers' compiled output (IsTool),
so this is scanner noise rather than a real exploit path.

## [3.2.1] - 2026-08-31

### Security
Expand Down Expand Up @@ -206,8 +219,9 @@ and this project adheres to [Semantic Versioning](http://semver.org/).

- First release as NuGet package

[Unreleased]: https://github.com/sillsdev/SIL.BuildTasks/compare/v3.2.1...master
[Unreleased]: https://github.com/sillsdev/SIL.BuildTasks/compare/v3.2.2...master

[3.2.2]: https://github.com/sillsdev/SIL.BuildTasks/compare/v3.2.1...v3.2.2
[3.2.1]: https://github.com/sillsdev/SIL.BuildTasks/compare/v3.2.0...v3.2.1
[3.2.0]: https://github.com/sillsdev/SIL.BuildTasks/compare/v3.1.1...v3.2.0
[3.1.1]: https://github.com/sillsdev/SIL.BuildTasks/compare/v3.1.0...v3.1.1
Expand Down
2 changes: 1 addition & 1 deletion SIL.BuildTasks/SIL.BuildTasks.csproj
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
<PackageReference Include="Markdig.Signed" Version="0.41.1" />
<PackageReference Include="Microsoft.Build.Tasks.Core" Version="18.9.6" />

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Worth noting that Microsoft.Build.Tasks.Core version 15.9.30 was the last version to build for a .NET Framework 4.6 version. From Microsoft.Build.Tasks.Core version 16 onwards that package depends on .NET Framework 4.7.2. So it's possible we will get some errors when we try to use SIL.BuildTasks from a net461 or net462 build (such as ChorusHub). However, #82 bumped the Microsoft.Build.Tasks.Core dependency from 17 to 18, so the net472 dependency issue was already present before SIL.Core was bumped.

Therefore, I'm not going to suggest downgrading the Microsoft.Build.Tasks.Core dependency down to 15 in this PR, because that .NET Framework version mismatch already existed before the SIL.Core version bump that this PR is intended to address. (The Microsoft.Build.Tasks.Core dependency was introduced in SIL.BuildTasks release 3.1.2-beta0002).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

SIL.BuildTasks' task assemblies aren't compiled into the product; they're loaded via <UsingTask> into whatever process is doing the build (MSBuild.exe or dotnet build's host), which runs on the .NET Framework/SDK installed on the build machine - not on the TargetFramework the project declares. A net461-targeting project can still be built by an MSBuild host running on 4.7.2+/4.8, with no relationship between the two.

So the real risk isn't "does the product target net46x" - it's "is the build machine itself frozen below 4.7.2," which would need an older VS/Build Tools install. Given #82 already bumped Microsoft.Build.Tasks.Core to 18 with no reported breakage, that doesn't seem to be happening in practice. I'd be surprised if any of our build agents/tooling are operating on .net 4.6.x.

(Even then, .NET Framework doesn't always hard-fail at load time just because a dependency was compiled against newer reference assemblies - it can still work unless a not-actually-present API gets called.)

<PackageReference Include="Microsoft.Win32.Registry" Version="5.0.0" Condition="'$(TargetFramework)'=='netstandard2.0'" />
<PackageReference Include="SIL.Core" Version="17.0.0" />
<PackageReference Include="SIL.Core" Version="9.0.0" />
<PackageReference Include="SIL.ReleaseTasks.Dogfood" Version="[2.3.3-*,)" PrivateAssets="All" />
</ItemGroup>
<ItemGroup>
Expand Down
Loading