From 33bf624ca1c9545647d24cea8fe48dc862e815e2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Jare=C5=A1?= Date: Sat, 5 Sep 2026 09:54:22 +0200 Subject: [PATCH 1/2] Reference System.Management.Automation from the oldest supported PowerShell MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The net8.0 assembly referenced System.Management.Automation 7.4.5.0, because the package reference was bumped to 7.4.6 to avoid a security advisory. .NET resolves an assembly reference forward to a newer version, but never backward to an older one, so on PowerShell 7.4.0 to 7.4.5 that reference cannot be satisfied and the import fails. The error does not say that. Import fails on the first type that inherits from a type in System.Management.Automation, which is PesterConfigurationDeserializer, and Update-TypeData reports 'Cannot convert "PesterConfigurationDeserializer" from String to Type'. PesterConfiguration itself derives from System.Object, so it still resolves and the existing version guard in Pester.psm1 passes. The advisory does not apply to this reference. We ship Pester.dll and nothing else, System.Management.Automation comes from the host PowerShell, so raising the number here patches nothing for anyone, it only drops support for the patch releases below it. Put the reasoning in the csproj next to the reference so it does not get bumped again. Added a test that reads the reference off the loaded assembly. 6.0.0 and 6.1.0 both shipped with 7.4.5.0 and nothing caught it. Fix #3013 🤖 --- docs/NEXT-RELEASE.md | 7 ++- src/csharp/Pester/Pester.csproj | 21 +++++++-- src/csharp/Pester/packages.lock.json | 52 ++++++++++++----------- src/csharp/PesterTests/packages.lock.json | 52 ++++++++++++----------- tst/Pester.Tests.ps1 | 13 ++++++ 5 files changed, 91 insertions(+), 54 deletions(-) diff --git a/docs/NEXT-RELEASE.md b/docs/NEXT-RELEASE.md index d7f02882f..de272e151 100644 --- a/docs/NEXT-RELEASE.md +++ b/docs/NEXT-RELEASE.md @@ -1,4 +1,4 @@ - + - - + + Microsoft only supports the latest patch of a line, so 7.4.0 itself is not a supported PowerShell, + 7.4.19 is. Referencing the baseline anyway means Pester still loads for people who are behind on + their PowerShell updates. That is deliberate. Whether their PowerShell is patched is their + decision, and a compile time reference is the wrong place to enforce it, especially when the way + it enforces it is an unreadable load error. We are not shipping them anything vulnerable. + + This is how it used to be done here. Before the net8 move this referenced 7.1.7, which was + older than 7.2.0, the oldest supported PowerShell at the time. --> + + +