Repository navigation
ConsoleApp hosting PowerShell fails when published as single file #13540
Description
Probably the wrong repo to report this and most likely I did something wrong. I get an exception when I try to create a runspace in a console application published as a single file. Runs fine when published normally.
Steps to reproduce
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.PowerShell.SDK" Version="7.1.0-preview.6" />
</ItemGroup>
</Project>
using System;
using System.Management.Automation.Runspaces;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var rs = RunspaceFactory.CreateRunspace();
Console.WriteLine("Hello World!");
}
}
}dotnet publish -r win-x64 --self-contained false /p:PublishSingleFile=true
Expected behavior
Hello World
Actual behavior
Unhandled exception. System.TypeInitializationException: The type initializer for 'System.Management.Automation.PSVersionInfo' threw an exception.
---> System.ArgumentException: The path is empty. (Parameter 'path')
at System.IO.Path.GetFullPath(String path)
at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
at System.Management.Automation.PSVersionInfo..cctor()
--- End of inner exception stack trace ---
at System.Management.Automation.PSVersionInfo.get_PSVersion()
at Microsoft.PowerShell.DefaultHost..ctor(CultureInfo currentCulture, CultureInfo currentUICulture)
at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace()
at ConsoleApp1.Program.Main(String[] args)
Environment data
dotnet --info
.NET SDK (reflecting any global.json):
Version: 5.0.100-preview.8.20417.9
Commit: fc62663a35
Runtime Environment:
OS Name: Windows
OS Version: 10.0.19041
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\5.0.100-preview.8.20417.9\
Host (useful for support):
Version: 5.0.0-preview.8.20407.11
Commit: bf456654f9
.NET SDKs installed:
5.0.100-preview.8.20417.9 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.NETCore.App 5.0.0-preview.8.20407.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 5.0.0-preview.8.20411.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Reacted by NN, Ben Lucato, Bobby Cannon, John Klann, Felipe Rios, Christopher Cook, Boris Zhao, Jerry, Elinora White, fabian-h and 1 more
Activity
iSazonov commentedon Aug 29, 2020
I tried to compile PowerShell to single file a month ago with the same result.
I guess the exception comes from follow line:
I found 29 such patterns in PowerShell code. And I don't know whether the exception is a .Net bug or we should use another pattern/workaround.
I think the scenario (single file) has a right to exist and we could support it in next milestone.
It is a question for PowerShell Committee.
/cc Steve Lee (@SteveL-MSFT) Dongbo Wang (@daxian-dbw)
fMichaleczek commentedon Aug 30, 2020
Ilya (@iSazonov) same problem occurs when trying to publish a Blazor webassembly with SMA. (Not the only one).
stwehrli commentedon Aug 31, 2020
My initial report is not entirely correct. I claimed that a normal publish works. That's not true, at least not on my box. It works fine with a simple build in release mode from Visual Studio 2019 Preview.
However, as soon as I publish the solution with a runtime identifier (which is required for single file publish), the binary explodes upon startup. Publishing to win-x64 does not work.
daxian-dbw commentedon Aug 31, 2020
Ilya (@iSazonov) We need to first understand what is the problem before having the committee involved.
iSazonov commentedon Sep 1, 2020
Dongbo Wang (@daxian-dbw) My question is does PowerShell team want to support single file build scenario? If yes we can start to investigate problems in implementation of the scenario.
fMichaleczek commentedon Oct 7, 2020
API incompatibility :
Recommendations :
Other considerations
Source : Single file deployment and API incompatibility
fMichaleczek commentedon Oct 7, 2020
Actual behaviour :
PowerShell/src/System.Management.Automation/engine/PSVersionInfo.cs
Lines 79 to 80 in 4b9b078
should be replaced by a safer way to get the product info (from the custom attributes of the assembly)
ptupitsyn commentedon Nov 30, 2020
Any update on this issue? Seems to be a trivial bug to fix.
Same here, both Windows and Linux. Powershell does not work from single-file apps. Tried the latest preview NuGet as well (
7.2.0-preview.1).fMichaleczek commentedon Nov 30, 2020
Pavel Tupitsyn (@ptupitsyn) no update at this moment. I am working to submit a PR for Wasm. I'm not sure if it will cover everything need for single file app. Do you want to make a contribution ?
iSazonov commentedon Dec 1, 2020
You could search by Regex "Assembly.*.Location" to find all such patterns we would have to fix.
ptupitsyn commentedon Dec 1, 2020
Flavien MICHALECZEK (@fMichaleczek) had a closer look at the code - looks like I underestimated the fix, there are multiple places that need updating, including native libraries handling. Not considering a contribution right now, sorry :(
37 remaining items
RobinGFT commentedon May 14, 2024
Push!
On year later this issue is still present with .NET 8 and PowerShell.SDK 7.4.2.
As soon, as I want to build as single file, the appication doesn't run anymore and throws following error at the first execution of a powershell script:
I fiddled together a custom installer, with a lot of powershell scripts and a lot of dependencies. In normal mode the project is building such a mess on files, that it is hard to find the executable.
Will Microsoft provide a fix?
With .NET and PowerShell sharing Microsoft as their mother, I didn't expect to run into such a trouble...
hemanth307 commentedon Nov 22, 2024
I am facing the Same issue Sir RobinGFT. Have you found any solution to this issue.
RobinGFT commentedon Nov 26, 2024
Hi hemanth307,
I'd created a new issue here: #23797 and it seems, that Steve Lee (@SteveL-MSFT) worked on it in #24072 and already merged into master. However I'm not sure, if it has wandered into a officially build (or NuGET) already, I can't find any mentioning in the releases and with the newest NuGET package it is still not working for my case.
fMichaleczek commentedon Nov 26, 2024
RobinGFT the change is merged in SDK 7.5 Preview release, available on NuGet.org
RobinGFT commentedon Nov 27, 2024
Ok, I just had a look and updated to SDK Preview version 7.5.0-rc1 and tested with both .net 8 ad .net 9 , but the issue is still the same:
ERROR: 2024-11-27T09:29:24.9296259Z - Value cannot be null. (Parameter 'path1') at System.ArgumentNullException.Throw(String paramName) at System.IO.Path.Combine(String path1, String path2) at System.Management.Automation.PSSnapInReader.ReadEnginePSSnapIns() at System.Management.Automation.Runspaces.InitialSessionState.CreateDefault() at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(PSHost host) at System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace() at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync) at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection1 input, PSDataCollection1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection1 input, PSDataCollection1 output, PSInvocationSettings settings) at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection1 output, PSInvocationSettings settings)at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke()
at GFT.Installer.CommonInstaller.clsInstallExecutor.runFromPowerShellWithArgs(String cmd, Object[] args) in D:\07_GIT\gitlab.projectserv\Installer\CommonInstaller\clsInstallExecutor.cs:line 50`
The errors is thrown while executing following code:
string cmdPermissionCheck = "$currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) \r\n" + "if(!$currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)){ \r\n" + " return -1 \r\n" + "} \r\n" + "return 1";mr-const commentedon Dec 17, 2024
I have the very same problem on 7.5.0-rc1 net9.0, but with a little bit different call stack:
nikgoodley-ibboost commentedon Jan 3, 2025
I can confirm RobinGFT's observations, even using the 7.5.0-rc.1 seems to have the same issue (though I couldn't entirely rule out some kind of conflict due to various PS versions).
Having both this and #23797 "closed" (and possibly #24070) makes it unclear whether anyone at MSFT is aware this bug remains or whether another issue needs to be raised to ensure there are eyes on it?
I am not sure if the change mentioned in #24072 reflects completely the changes mentioned as necessary in this comment.
I can see in this commit from Steve Lee (@SteveL-MSFT) that the GetApplicationBase has been changed, which is ultimately I think where we see the problem arising, via this line.
But then I'm not clear what's missing, whether it's not actually reaching the fallback approach of using
baseDirectory = AppContext.BaseDirectory.TrimEnd(Path.DirectorySeparatorChar);Certainly in my local single file examples, if I had
System.Reflection.Assembly.GetExecutingAssembly().LocationI would have to change them toAppContext.BaseDirectoryin single-file publication and that works. So I'm not sure why this then would still be returning null.With the attachment below, in an environment with the 7.5.0-rc.1 SDK and latest dotnet, running the Build.ps1 replicates the issue if this is of any use.
ps-integration.zip
Note this fails in the Invoke but it would fail on the PowerShell.Create() call if changed to
using var ps = PowerShell.Create(InitialSessionState.CreateDefault());nikgoodley-ibboost commentedon Jan 3, 2025
Hmm, I tried building PowerShell locally and changed my test app's
.csprojfromto this (expanding to cover the packages it complained about at compile time)
And then it did finally seem to work.
I rarely touch .Net so perhaps this is obvious about the build system but I'm not very clear on why this works locally yet changing the package references wouldn't if the change was incorporated per the earlier comment.
I tried changing the ItemGroup references to
7.5.0-rc.1,7.5.0-preview.3(since when I started the built pwsh this showsPowerShell 7.5.0-preview.3-222-gc0d7fb787f025dffdcc4ea8a05e65004e9e71d66and pwsh reports its version as7.5.0-preview.3though I don't see reference to this string in the repo) and7.5.0-preview.5since that appears on https://www.nuget.org/packages/Microsoft.PowerShell.SDK/7.5.0-rc.1#versions-body-tab but none of these worked.I presumed this was my misunderstanding... but then I checked out the packaged source under the latest rc1 release https://github.com/PowerShell/PowerShell/archive/refs/tags/v7.5.0-rc.1.zip and it does not have SteveL-MSFT's change. Not visible in https://github.com/PowerShell/PowerShell/blob/v7.5.0-rc.1/src/System.Management.Automation/engine/Utils.cs#L483
Dongbo Wang (@daxian-dbw) could there be some problem with the tagging/branching or is there some other reason #24072 wouldn't be incorporated?
fMichaleczek commentedon Jan 3, 2025
Nik Goodley (@nikgoodley-ibboost) Don't hesitate to read the dotnet runtime design doc and how the msbuild setting impact the compilation. At the end, you will understand that there is no single file without having to rethink the application or with the exclusions it does not look like a single file. I don't think Microsoft will deploy it and if we consider the PAM mode (PowerShell Application Mode) aka the Microsoft.PowerShell.SDK, the developer must go read the dotnet design docs and not PowerShell.
PowerShell is already slow at startup, adding compression is not good for 100MB.
https://github.com/dotnet/designs/tree/main/accepted/2020/single-file
nikgoodley-ibboost commentedon Jan 4, 2025
Hi Flavien, thanks for the pointer on the design doc, I hadn't seen it but nevertheless the points it makes were mostly known to me. Understood on general principle; not sure if I'm missing something specifically relating to my comments on the PowerShell build process/resolution of this ticket though?
The change is already made (and really could be seen as a natural consequence of https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design_3_0.md#api-impact) the question was why #24072 has been merged but the releases don't address the actual issue since you'd said
however, I'm confirming that all of these 7.5 preview versions still have the same issue. The original question and with Robin's comment being unanswered since November was whether the fix from SteveL-MSFT needed more or if it just wasn't in the builds for some reason.
Seems it's the latter. I've gone through all five 7.5 preview versions and it wasn't in any but I've just seen the one cut three weeks ago for 7.6.0-preview.1 actually says #24072 in the release notes https://github.com/PowerShell/PowerShell/releases/tag/v7.6.0-preview.1 and I see the change affecting this problem in Utils.cs. It just isn't yet in nuget.org (and the master branch doesn't reflect this version), that's the confusing point.
So the answer is just we have to wait until 7.6 is published or build from source ourselves, I guess.
fMichaleczek commentedon Jan 14, 2025
I create a script to download/patch/build the source published as single file for Windows with SDK 9.0 Build 101
https://gist.github.com/fMichaleczek/9ac6d8739149917fa1cf18e3e89ffcae
There is broken features (Get-Help for Core Modules).
RobinGFT commentedon Jan 17, 2025
Version 7.6.0-preview.2 found its way into official NuGet package manager. I upgraded my project via VisualStudio and either build and run where succcesfully. It seems the problem is finally solved 😅😎
I will do several more tests and write feedback here, if there turn up some more issues.
At the moment I'm happy 🥳😅
fix bug with single file publish
Fix Rowan portable build by dropping -PublishSingleFile (open PowerSh…