.Net 4 and PowerShell V2

[iHunger]

If you create a powershell module using a dll that references .Net 4, when you attempt to import it in PowerShell V2, it complains about the runtime version. It is possible to do global changes to allow .Net 4 to run in Posh v2, but is there a better way to achieve this?

Reference:
http://stackoverflow.com/questions/2094694/how-can-i-run-powershell-with-the-net-4-runtime
http://viziblr.com/news/2012/5/16/the-easy-way-to-run-powershell-20-using-net-framework-40.html

[MattG]

Unfortunately, you'll have to choose one or the other. I'd say that if you're going to load the dll frequently enough into your PowerShell sessions then you should just have it always load .NET v4. Can you think of any reason why you still need .NET v2 to be loaded? If not, I would stick with v4.

[poshoholic]

Hi Jim,

Just thinking out loud, you could probably manage this with PowerShell. For example, have a command in your profile that creates the config file so that PowerShell launches with .NET 4 and then invoke PowerShell in a nested prompt to get v4 "on demand", removing or renaming that config file when you finish (i.e. when you return from the nested session). Another possibility would be to use different hosts, one for v2 work with .NET 2 and another for v2 work with .NET 4. For example, native PowerShell with .NET 2, and one of the third party free editors configured with .NET 4. Then you just need to pick the right environment for the job. I'm sure there are other possibilities as well via scripting. I haven't tried these myself, but the flexibility is there for you to achieve what you need.

Also, Matt, one reason someone might want to stick with .NET v2 is SharePoint. SharePoint 2010 PowerShell does not work with .NET 4 afaik.

[iHunger]

Thanks Kirk/Matt

In this case the PowerShell module will be signed and redistributed with a commercial application. Life is certainly easier if we can use .NET 4 when we write the dll, but then we will either have to tell the user how to enable .NET 4 support or provide a method to automatically change their environment. Neither sounds especially appealing. I was hoping that someone had run into this issue and come up with a good solution. I'll let you know if we come up with anything ingenious.

Jim Hofer (@iHunger)

[iHunger]

Found some more information on this - http://connect.microsoft.com/PowerShell/feedback/details/525435/net-4-0-assemblies-and-powershell-v2

Most recent comment says:

Using PowerShell 2.0 with .NET Framework 4.0 is not supported. This is due to some changes in the runtime activation policy of CLR 4 which prevent applications built against CLR 2 from automatically rolling forward to CLR 4. More details about these changes are described in the "In-Process Side-by-Side" article in MSDN Magazine at http://msdn.microsoft.com/en-us/magazine/ee819091.aspx.

While it is possible to force PowerShell 2.0 to run with .NET Framework 4.0 using various mechanisms such as creating a config file for PowerShell or editing the registry, these mechanisms aren't supported and can have negative side effects on other PowerShell functionality such as PowerShell remoting and cmdlets with mixed-mode assemblies.

We've added support for .NET Framework 4 in Windows PowerShell 3.0. If you cannot take a dependency on Windows PowerShell 3.0, then you should continue to use .NET Framework 2.0 or 3.5. If you have a hard dependency on .NET Framework 4 for creating cmdlets, scripts, hosts, etc., you will need to use Windows PowerShell 3.0.