Issue while upgrading API Service from .Net 8.0 to .Net 10.0

Thanks @Gade Harika (INFOSYS LIMITED) for the reply.

I cannot change the Powershell Version in Octopus Deploy unfortunately as it may impact few other working modules.

Also downgrading the runtime target is also not possible.

If you can eloborate more on the first two points, it would be great--

• Ensure the generated assembly has no dependency on .NET 10 APIs
• Generate the assembly outside PowerShell and only consume simple types

Thanks

Thanks for the clarification.

Since PowerShell 5.1 cannot be changed and downgrading the .NET runtime isn’t possible, the issue must be solved by isolating modern .NET usage from PowerShell.

1) Ensure the generated assembly has no dependency on .NET 10 APIs

Although the parent library targets netstandard2.0, the runtime‑generated assembly may still reference modern .NET runtime components or APIs introduced after .NET Framework compatibility. PowerShell 5.1 runs on .NET Framework and cannot load such assemblies, which results in “Unable to find type” errors.

To make this work, the generated assembly must:

• Be strictly limited to netstandard2.0 APIs
• Avoid references to netcoreapp, net10.0, or Microsoft.Extensions.*
• Avoid modern runtime features (e.g., newer System.Text.Json, runtime loaders)

Even then, PowerShell 5.1 remains fragile with dynamically generated assemblies.

2) Generate the assembly outside PowerShell (recommended approach)

The most reliable solution is to move all runtime generation and execution logic into the .NET 10 application and let PowerShell act only as an orchestrator.

In this model:

• The .NET 10 app generates and executes the assembly
• The result is written to disk or exposed via API (JSON / XML / simple DTOs)
• PowerShell 5.1 only consumes serialized data and does not load the assembly

This avoids runtime incompatibilities entirely and is the recommended pattern when PowerShell 7 cannot be used.

Let me know if you need any further help with this. I will be happy to assist. If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

More details on approach 2 would help. Thanks

Thanks for the additional details. Since you can’t switch Octopus to PowerShell 7 and can’t downgrade the runtime, the most reliable fix is to stop loading/executing the runtime-generated assembly inside Windows PowerShell 5.1.

Windows PowerShell 5.1 runs on .NET Framework, and modern .NET (net10.0) uses different assembly loading/resolution behavior. With dynamically generated assemblies this often shows up as “Unable to find type …” because the type never successfully loads into the PS 5.1 process. [Resolving...soft Learn | Learn.Microsoft.com]

Recommended workaround (Approach 2 – detailed):

1. Create a small .NET 10 helper console app that performs the runtime generation + loads/executes the generated assembly within the .NET 10 process.
2. Have the helper write results as JSON to stdout (or to a file).
3. In Octopus, keep the step as PowerShell 5.1, but call the helper (RuntimeGenHelper.exe …) and parse the JSON using ConvertFrom-Json. [learn.microsoft.com]

Example: PowerShell 5.1 script calling the helper

Run helper and capture JSON to stdout $helper = ".\RuntimeGenHelper.exe"   # self-contained publish recommended

$json = & $helper --input ".\config.json" 2>&1

Convert JSON -> PowerShell object $result = $json | ConvertFrom-Json

if (-not $result.success) {

    throw "Helper failed: $($result.error)"

}

Write-Host "GeneratedAssemblyPath: $($result.generatedAssemblyPath)"

Write-Host "ValueFromExecution: $($result.value)"

This way PowerShell acts only as an orchestrator and never needs to load the generated assembly—so the .NET Framework compatibility limitation is avoided. This pattern is commonly used in deployment pipelines that mix PowerShell steps with .NET application execution. [octopus.com]

Let me know if you need any further help with this. I will be happy to assist. If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Hope you’re doing well. We’re following up on this thread to check if the issue is still occurring or has been resolved. If it has been resolved, kindly mark the answer as Accepted. We will proceed with thread closure by March 20th.