Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PowerShell Core for Windows - add the "Run as Administrator" action to taskbar button. #6649

Closed
rkeithhill opened this issue Apr 13, 2018 · 7 comments · Fixed by #6913
Closed
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-Fixed The issue is fixed.

Comments

@rkeithhill
Copy link
Collaborator

With Windows PowerShell pinned to my taskbar, I can easily run it as an administrator with the action at the top:

image

But with PowerShell Core, this action is missing:

image

Yeah, I know I can right click on PowerShell-6.x.x and then get the option to run as admin but that is buried UI and is harder to find than it should be.

@TravisEz13 TravisEz13 added the Issue-Enhancement the issue is more of a feature request than a bug label Apr 14, 2018
@KevinMarquette
Copy link
Contributor

I did some quick research on this one and it looks like the old code for this is still here:

HRESULT AddPowerShellTasksToList(ICustomDestinationList *pCustDestList, STARTUPINFO &startupInfo)
but I can't tell that it gets called anywhere. At a glance, this looks like it needs to be refactored.

@SteveL-MSFT
Copy link
Member

@KevinMarquette the nativemsh code is no longer built as of PSCore6 we've gone with a full managed code host. Seems like we should reuse that code in the managed host on Windows.

@SteveL-MSFT SteveL-MSFT added this to the 6.1.0-Consider milestone Apr 18, 2018
@bergmeister
Copy link
Contributor

Thanks @KevinMarquette for the research. I will take a look at this one as I would be interested in having this feature as well.

@bergmeister
Copy link
Contributor

bergmeister commented May 13, 2018

@SteveL-MSFT
I got a simple prototype that works but does not do the elevation. Before proceeding I would like to discuss if my approach is acceptable.
To avoid having to write unsafe code, I used the Microsoft.WindowsAPICodePack-Shell and Microsoft.WindowsAPICodePack-Core NuGet packages from MSFT that are compiled in full .Net 3.5 (but work in netcore 2.1 for our purposes due to fallback) and therefore I have to suppress NU1701 for the Microsoft.PowerShell.ConsoleHost project. The 2 DLLs add 634KB of footprint in total. Would you be OK with that? I exclude Linux in the custom code, I assume Win-ARM needs to be excluded as well? Due to missing methods in the NuGet packes, elevation is outstanding and I would need a COM pointer to the shelllink for calling the IShellLinkDataList interface on it. Unfortunately the NuGet packages are a complete COM wrapper and do not expose the private low level pointers to the shell objects (or do you maybe you know a trick for that?) and the ICustomDestinationList interfaces also do not offer Get methods. The Microsoft.WindowsAPICodePack package is not maintained/supported by Microsoft any more by the way.
To conclude: It seems I would need to modify and recompile the WindowsAPICodePacks in order to add the missing methods for elevation or one would would have to rewrite all that C++ code from Windows PowerShell to C# but since it is mainly using COM to talk to the Windows API it is not really managed code anyway and it will be quite a bit of work. What are your thoughts on the direction?
My crude prototype is here. Any comments/pointers on the code, like e.g. its place in ConsoleHost would be appreciated. By looking at the test results, it seems I need to check if the account running pwsh is interactive (I would check `Environment.UserInteractive) and also if the current pwsh process is the parent process and was not launched from a different shell (e.g. Windows PowerShell or when calling pwsh from pwsh).
image

@SteveL-MSFT
Copy link
Member

@bergmeister it seems that with the additions you would need to add to that library, it's not really providing good value to cost. My recommendation would be to write new C# code to wrap the COM code.

@bergmeister
Copy link
Contributor

Thanks for the feedback, I had some success.
I first gave it a try to convert the C++ code to C# myself but it is kind of hairy due to the APIs requiring special structures like PropVariant that are non-trivial to implement in C#. I then took the approach of decompiling some of those structural equivalents from the WindowApiPack NuGet packages and when I finally had the bits together, the COM calls started to fail in the middle of it.
My second, more successful approach was to take the whole source code of the WindowApiPack packages and port it to .Net Core by removing various classes/methods referencing stuff like WinForms, etc. I added then my needed IShellLinkDataList calls for elevation and voila, I have now a working proof of concept 😃
Armed with that now, I will try to see if I can get my first, more minimal approach working or otherwise I will look into minimising the code of my customised WindowApiPack packages.

@bergmeister
Copy link
Contributor

bergmeister commented May 27, 2018

@rkeithhill Can you please amend the title to remove the word Installer since nothing happens at install time.

@rkeithhill rkeithhill changed the title PowerShell Core Installer for Windows - add the "Run as Administrator" action to taskbar button. PowerShell Core for Windows - add the "Run as Administrator" action to taskbar button. May 27, 2018
TravisEz13 pushed a commit that referenced this issue May 31, 2018
Closes #6649

This is a port of existing C++ Windows PowerShell code from MainEntry.cpp
Some of the code has been copied and minified from the WindowsApiPack.

The code is not compiled for Linux (not sure also another condition is needed for Windows on ARM?).
The code checks if the PowerShell process has a window handle by checking the startupinfo and only then tries to populate the list (and also checks if there is a slot available in the jumplist).
Tested on Windows 10 1803, jumpLists have been supported in Windows since Windows 7, which matches what PowerShell Core supports.
@iSazonov iSazonov added the Resolution-Fixed The issue is fixed. label Jun 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-Fixed The issue is fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants