PolicyPak Cloud v26.10.4774 — Patch Notes

[JBogalecki (Jarosław Bogalecki)]

We would like to notify you that we have just released a patched version of PolicyPak Cloud Client, v26.10.4774, it is available for download directly in PolicyPak Cloud Portal, thereby replacing both the previously withdrawn v26.9.4752 and the v26.7.4696 which had temporarily been restored in its place. The primary purpose of this patch is to mitigate the .NET 10 runtime-related issues reported by some customers following the release of the previous version of PolicyPak Cloud.

Details of Patch v26.10.4774

---

This new Client will install .NET 10 only if it is not already installed on a machine and the default installation path will be the one recommended by Microsoft, namely C:\Program Files\dotnet\. You will also find a new DOTNETROOTFOLDER parameter in the installer which will allow you to specify a custom installation directory for .NET 10. If you choose to specify this DOTNETROOTFOLDER parameter, the DOTNET_ROOT_X64 environmental variable will link to it moving forward. If you do not, then the DOTNET_ROOT_X64 environmental variable will be set to C:\Program Files\dotnet\.

We would like to emphasize that if a machine’s .NET 10 runtime is the one installed previously by PolicyPak Cloud v26.9.4752, then it will be found at C:\Program Files\PolicyPak\Cloud\dotnet\ and that is what the DOTNET_ROOT_X64 environmental variable will link to. In that scenario, when you install this new Client version, it will detect .NET 10 at that location and therefore will implement no changes to the existing .NET 10 structure, which means that .NET 10 will continue to exist at that PolicyPak-dependent path. If you would like to recover the Microsoft-recommended location, the best way is to first download .NET 10 from the Microsoft website, reset the DOTNET_ROOT_X64 environmental variable to C:\Program Files\dotnet\ and then proceed to install the new Client version. That will ensure a complete removal of any sort of dependency of your .NET 10 on a local PolicyPak folder.

Need help with this update?

There are many different ways to get help with our products!

Situation	Action
If you feel the product is broken and not working as intended…	Contact Support
If you have a question you’d like to ask other experts…	Create a discussion in the community: PolicyPak > PolicyPak Discussions & Questions
If you have a feature request…	Let our product team know directly: PolicyPak > PolicyPak Ideas
If you have something cool to show…	Show everyone what you built: PolicyPak > PolicyPak Show & Tell

What are your thoughts?

We are always happy to hear from our users on what you like, and what you hope to see in the future. Please, share your thoughts below!

[goldensparrow (Luke Manning)]

Thanks for moving .NET 10 back to the Microsoft default installation location.

I have two questions about setting the machine-wide DOTNET_ROOT_X64 environment variable:

1. My understanding is that on Windows ARM64, Microsoft installs the native ARM64 runtime under C:\Program Files\dotnet, while the x64 runtime is installed under C:\Program Files\dotnet\x64. Wouldn’t setting DOTNET_ROOT_X64 to C:\Program Files\dotnet therefore cause x64 PolicyPak components or other x64 applications running under emulation to resolve the wrong runtime location? Alternatively, is this change limited to x64 Windows?

2. Is it necessary to set DOTNET_ROOT_X64 machine-wide when .NET is installed in its standard location? My understanding is that the .NET app host can discover a standard system-wide installation through its registered installation location. A machine-wide override may also affect unrelated .NET applications. If PolicyPak requires an explicit runtime path, could it instead be scoped only to the PolicyPak processes or services, with the architecture-appropriate path used on ARM64?

The goal would be to avoid globally overriding .NET runtime discovery unless PolicyPak genuinely requires it.

[JBogalecki (Jarosław Bogalecki)]

Hi, Luke, thanks for reaching back.

@goldensparrow

1. My understanding is that on Windows ARM64, Microsoft installs the native ARM64 runtime under C:\Program Files\dotnet, while the x64 runtime is installed under C:\Program Files\dotnet\x64. Wouldn’t setting DOTNET_ROOT_X64 to C:\Program Files\dotnet therefore cause x64 PolicyPak components or other x64 applications running under emulation to resolve the wrong runtime location? Alternatively, is this change limited to x64 Windows?

No, as per Microsoft documentation, “DOTNET_ROOT_X64 is used for an x64 process. This process might be running on x64 or Arm64 architecture.” Moreover, we have run tests and the new Client is properly supported on both architectures.

@goldensparrow

2. Is it necessary to set DOTNET_ROOT_X64 machine-wide when .NET is installed in its standard location? My understanding is that the .NET app host can discover a standard system-wide installation through its registered installation location. A machine-wide override may also affect unrelated .NET applications. If PolicyPak requires an explicit runtime path, could it instead be scoped only to the PolicyPak processes or services, with the architecture-appropriate path used on ARM64?

No, as I mentioned in the Patch Notes: the new PolicyPak Cloud Client will detect .NET 10 no matter where it’s installed on the system. So if you have it in a standard location, like C:\Program Files\dotnet\x64, then the installer will realize this and simply not bother to install .NET 10 again. Everything should work smoothly from then on.