Introduction

This question is mostly about Windows PowerShell, not modern PowerShell 7. Historically, Windows PowerShell 2.0 was tied to the older CLR 2 runtime, while Windows PowerShell 3.0 and later already ran on the .NET Framework 4 CLR, so the right answer depends first on which PowerShell host version you are actually starting.

Check Which PowerShell You Are Using

Start by checking the PowerShell version:

$PSVersionTable.PSVersion

If you are on Windows PowerShell 3.0 or later, you are already in the .NET 4 generation of the runtime. In that case, there is usually nothing special to configure just to "run PowerShell with .NET 4."

If you are specifically dealing with Windows PowerShell 2.0, the situation is more historical and host-dependent. That is where the config-file approach enters the picture.

It is also worth separating product lines:

• Windows PowerShell 2.0 through 5.1 is the .NET Framework-based product line
• PowerShell 7 and later runs on modern .NET, not .NET Framework 4

So the .NET 4 runtime question is mainly relevant to older Windows PowerShell scenarios.

The Historical powershell.exe.config Approach

For legacy situations where you need an older PowerShell host to load under CLR 4, the classic technique is to use an application config file for the executable host.

The configuration looks like this:

1<?xml version="1.0"?>
2<configuration>
3  <startup useLegacyV2RuntimeActivationPolicy="true">
4    <supportedRuntime version="v4.0.30319"/>
5  </startup>
6</configuration>

This is typically placed in a file such as powershell.exe.config next to the host executable. The key points are:

• 'supportedRuntime points to CLR 4'
• 'useLegacyV2RuntimeActivationPolicy helps older CLR 2-targeted components coexist with the CLR 4 host policy'

This is a host-level configuration, not something you toggle from inside a script after PowerShell has already started.

Know When You Do Not Need to Do This

Many discussions of this topic are older than the current Windows PowerShell defaults. If your machine is already using Windows PowerShell 3.0, 4.0, or 5.1, the shell already runs in the .NET Framework 4 era.

In those cases, editing powershell.exe.config is unnecessary and may only create confusion. A better first check is:

$PSVersionTable

If the host is already modern enough for your use case, the real problem may not be the runtime at all. It may be:

• an assembly binding issue
• a module compiled for a different framework target
• a mismatch between 32-bit and 64-bit hosts

So do not reach for runtime config files before confirming that the host version is actually the limiting factor.

Use the Right Host for the Job

Another detail that trips people up is that powershell.exe, PowerShell ISE, and newer pwsh hosts are not interchangeable.

If your goal is specifically ".NET Framework 4 with Windows PowerShell," you are usually dealing with the classic Windows PowerShell host:

Get-Process -Id $PID | Select-Object Path

That shows which executable is hosting the current shell.

If you launch pwsh, you are in the modern PowerShell product line, which is a different runtime story entirely. That does not make it wrong; it just means the old ".NET 4 runtime" question is no longer the right framing.

Common Pitfalls

The biggest mistake is trying to solve a module or assembly compatibility problem by forcing a runtime change without checking the actual PowerShell version first. If you are already on Windows PowerShell 5.1, the shell is already in the CLR 4 generation.

Another issue is editing the host config file and expecting a running PowerShell session to change behavior immediately. Runtime selection happens when the host starts.

Developers also sometimes confuse Windows PowerShell with PowerShell 7. The former is tied to .NET Framework; the latter uses modern .NET and answers a different runtime question.

Finally, be careful with blanket system-wide host changes on shared machines. A config tweak for one legacy integration can affect every launch of that executable host.

Summary

• The .NET 4 runtime question mainly applies to older Windows PowerShell scenarios.
• Windows PowerShell 3.0 and later already runs in the .NET Framework 4 generation.
• For legacy host cases, the classic approach is a powershell.exe.config file with supportedRuntime version="v4.0.30319".
• Decide first whether the problem is really the runtime or a different compatibility issue.
• Do not confuse Windows PowerShell with PowerShell 7, because they are different host and runtime lines.