Microsoft.PowerShell.SDK Runspace Creation Exception with empty error message in .NET 6 with publish target win-x64

[peter-sidebotham]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

For Microsoft.PowerShell.SDK version 7.2.6 running on Windows 11 and Windows Server 2016:
If you publish a .NET 6 console application (or any other exe type) with target framework win-x64 (instead of e.g. win7-x64)
There is an exception with an empty string message when you call: RunspaceFactory.CreateRunspace(InitialSessionState.CreateDefault())

The issue occurs with published binaries, when the output runtime is set to win-x64.

The error has no message or inner exception, but has the following stack trace:
System.Reflection.RuntimeAssembly.GetExportedTypes(QCallAssembly assembly, ObjectHandleOnStack retTypes) at System.Reflection.RuntimeAssembly.GetExportedTypes() at System.Management.Automation.Runspaces.PSSnapInHelpers.GetAssemblyTypes(Assembly assembly, String name) at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzeModuleAssemblyWithReflection(Assembly assembly, String name, PSSnapInInfo psSnapInInfo, PSModuleInfo moduleInfo, String helpFile, Dictionary2& cmdlets, Dictionary2& aliases, Dictionary2& providers) at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzePSSnapInAssembly(Assembly assembly, String name, PSSnapInInfo psSnapInInfo, PSModuleInfo moduleInfo, Dictionary2& cmdlets, Dictionary2& aliases, Dictionary2& providers, String& helpFile) at System.Management.Automation.Runspaces.InitialSessionState.ImportPSSnapIn(PSSnapInInfo psSnapInInfo, PSSnapInException& warning) at System.Management.Automation.Runspaces.InitialSessionState.CreateDefault()

The following is a minimal project to reproduce the issue.

Project file:
`

Exe net6.0-windows PowerShellTest PowerShellTest true true true true win-x64 true embedded True x64 bin\Debug embedded True x64 bin\Release `

Publish File:
<Project> <PropertyGroup> <Configuration>Release</Configuration> <Platform>x64</Platform> <PublishDir>publish\</PublishDir> <PublishProtocol>FileSystem</PublishProtocol> <_TargetId>Folder</_TargetId> <TargetFramework>net6.0-windows</TargetFramework> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <SelfContained>true</SelfContained> </PropertyGroup> </Project>

Program.cs File:
`using System;
using System.Management.Automation.Runspaces;

namespace PowerShellTest
{
class Program
{
static void Main(string[] args)
{
try
{
var runspace = RunspaceFactory.CreateRunspace(InitialSessionState.CreateDefault());
runspace.Open();
}
catch (Exception e)
{
Console.WriteLine($"Error: {e.Message}\r\n{e.StackTrace}");
}
}
}

}`

Expected behavior

Program runs without printing output

Actual behavior

Program prints:
Error:
--stack trace--

Error details

No response

Environment data

N/A see SDK setup information in issue text

Visuals

No response

[ALIENQuake]

@peter-sidebotham
I will try to summarize what I already know about the problem of setting RuntimeIdentifier to the portable ones, without specifying the windows version.

• Despite the error, you will face another one: Could not load file or assembly 'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' because the file "Microsoft.Management.Infrastructure.dll" is not published into the "Publish" output.
• the reason for that is:

Microsoft.Management.Infrastructure.dll depends on mi.dll which is the native implementation. mi.dll depends on various Windows APIs. There is a difference between those APIs / native binaries which makes us use runtime folders for each supported OS PowerShell/MMI#45 (comment)

• mi.dll is written using managed-c which is not supported by NET 5+
• in order to fix this it would require rewriting mi.dll into c# but there are no plans for it: Microsoft.Management.Infrastructure NuGet package missing dependencies #4562 (comment)

So you need to provide non-portable RIDs if you want a self-contained app.

[peter-sidebotham]

Thank you @ALIENQuake, that makes a lot of sense. If nothing else, this issue could probably be solved by adding a note to the SDK documentation (unless there's a way to generate a self-contained portable target compile-time warning which would be even better). More than the limitation itself, the problem is that there doesn't appear to be a way to discover it until it crops up at runtime in application testing.

[daxian-dbw]

Close as a duplicate of #15274

[ghost]

This issue has been marked as duplicate and has not had any activity for 1 day. It has been closed for housekeeping purposes.