Powershell: Feature: Windows Installer to offer option of context menu to open PowerShell in explorer

[bergmeister]

As a user, I often want to start PowerShell in the current directory in which I am browsing in explorer.exe.
Being able to have a context menu so that I can just right click and select Open PowerShell here or Open PowerShell as Admininstrator here would be very useful. Although a user can setup this manually via the Windows registry (see e.g. here), this is a tedious process that is often not worth the effort and therefore should rather be replaced by an option in the installer.
What do you think?

[SteveL-MSFT]

I think if you can make it a checkbox in the installer, then it seems like a great feature.

[xee5ch]

I have been meaning to learn about WiX for years now, and a quick examination shows this is a WiX-based installer. Can I take a stab at this?

[bergmeister]

Yes, it is a WiX based installer and quite a simple one, which is great to get started (all you need to have installed is the WiX toolset here). I have not started on it yet, so feel free to give it a try and also ask any questions you have. :)
It is very easy to build the installer via this PowerShell function here and you do not even need to build the whole PowerShell project, you could just point the -ProductSourcePath parameter to a bin folder of a dummy project as long as it contains a file named powershell.exe (this is just a tip if you want to speedup compilation). When you run it you will see some warnings but you can ignore them. The script will always tell you where the expected MSI will be, even if there was an error, which means if you cannot find the MSI, you need to search for the WiX error in the verbose output.
What you will need to do is basically creating and setting registry entries, which means that this action needs to happen in the part where the installer runs with elevated rights, i.e. you will probably need to create a new dialogue with 2 checkboxes. As part of this you will learn that WiX checkboxes to not give you true/false values but instead you need to check if the associated variables value is either set or not.
Note that the example link that I have given at the top uses HKEY_CLASSES_ROOT but it might be better to use HKEY_CURRENT_USER. In terms of registry entries, I found that 2 entries need to be added:

• One in the Directory\Background folder to enable the context menu when right clicking any where in explorer
• Another one in Directory\shell to enable the context menu when right clicking on a specific folder
  The syntax between the 2 will be slightly different

You will find that there are already folders named Powershell of Windows PowerShell in the registry so you will need to come up with a new folder name, so maybe PowerShellCore6? Since the installer does not allow side by side installation any more, a version number is not needed at the moment but it might be better since this might change in the future.,

[SteveL-MSFT]

@xee5ch consider this yours! I've assigned it to myself as GitHub won't allow me to assign it to you, but I don't want other people duplicating your work.

[xee5ch]

Ok. Not sure on the ETA. I am newbish to Powershell, love what's being done, and need to review how to get the registry keys for the context menu (I know that part) but need to figure WiX and how to get that together.

Hopefully will be back in the next few days with something passable. Thanks for the more welcome.

[xee5ch]

And just saw your comments, @bergmeister. Apparently, you did all the research for me. That will cut down turnaround time.

[SteveL-MSFT]

@xee5ch don't worry about rushing it. We'll keep having ~3 week releases (even after 6.0.0 final), so it'll get into a release eventually :)

[xee5ch]

Roger that. But the likes of you all throwing pointers in my direction so quickly will motivate me to be good about this.

[bergmeister]

@xee5ch : Are you still interested in doing this? If you want to we could also do it together as I found out today that with some of the new changes, it has become more difficult to compile in a local dev environment (I had to make some local hacks in order to use New-MSIPackage locally. In general the work could also be split into 2 parts: creating the new dialog with the checkboxes and then setting the registry values based on the user input.

[bergmeister]

I have created a new dialogue with 2 checkboxes for this feature in my branch here since this is the first custom dialogue and therefore required some WiX heavylifting. All one would need to do is setting the registry keys and wiring the action up to those 2 new checkboxes.
@SteveL-MSFT : Below is a screenshot of the dialogue, which comes after the installation directory dialogue. Any thoughts on the preferred wording/design? In theory I could add those checkboxes to the installation directory dialogue but I wanted to keep it rather separate.

Also, would you mind if I add something like a -DevBuild switch to New-MSIPackage because at the moment I have comment out some non-functional stuff to build it locally (the culprits are Start-NativeExecution and Get-PackageSemanticVersion).

[xee5ch]

I did mean to continue work on this. Sorry for the delayed reply. I needed to set up Windows VMs for this and that became an issue. I will start work on this again.

On November 5, 2017 8:05:15 AM EST, bergmeister [e-mail] wrote:

I have created a new dialogue with 2 checkboxes for this feature in my
branch
here
since this is the first custom dialogue and therefore required some WiX
heavylifting. All one would need to do is setting the registry keys and
wiring the action up to those 2 new checkboxes.
@SteveL-MSFT : Below is a screenshot of the dialogue, which comes after
the installation directory dialogue. Any thoughts on the preferred
wording/design? In theory I could add those checkboxes to the
installation directory dialogue but I wanted to keep it rather
separate.

Also, would you mind if I add something like a -DevBuild switch to
New-MSIPackage because at the moment I have comment out some
non-functional stuff to build it locally (the culprits are
Start-NativeExecution and Get-PackageSemanticVersion).

[bergmeister]

No worries, I suggest you also downstream the latest changes from master in your fork (see here on how to do that) and then cherry-pick my commit here to get the new dialogue.

[xee5ch]

Thanks for the help. I will definitely cherry pick as described.

On November 5, 2017 9:59:16 AM EST, bergmeister [e-mail] wrote:

No worries, I suggest you also downstream the latest changes from
master in your fork (see
here on how to do
that) and then cherry-pick my commit
here
to get the new dialogue.

[bergmeister]

Great. For a more detailed explanation of what I have done see here. This link will also be useful to you because you can take the 2nd code block in the section Adding a checkbox to conditionally install a desktop shortcut as a base example for your work. I have also just pushed a 2nd commit here with an improvement that they would definitely ask you to do anyway at the PR stage.

[SteveL-MSFT]

@bergmeister I thought the original ask is a checkbox like:

[ ] add PowerShell Core to Context Menu

Where the context menu in Explorer would have the two options:

Open PowerShell Core here
Open PowerShell Core as administrator here

[bergmeister]

@SteveL-MSFT I was thinking of offering the user the choice between either or both context menu entries but if you prefer only one checkbox that includes admin and nonadmin then that's of course fine as well. And yes, the context menu would then look like as you described it.

[SteveL-MSFT]

@bergmeister apologies, I misread your screenshot. Since Windows doesn't have sudo, I think users will typically want/need both admin and non-admin.

[xee5ch]

So I spent the afternoon playing with this and no matter what string value I give to the ProductVersion argument of New-MSIPackage function in build.psm1, the Get-SemanticVersion call fails and does not bind a value to the necessary environment variable for the wxs declaration. I spent an hour or so on master pulling, resetting, and cleaning and I get the same result.

I had to step a way for a bit but will post the error tonight because also setting the environment variable directly did not seem to work, so I am at a loss.

[bergmeister]

@xee5ch Just replace the call to Get-SemanticVersion inside the function with a hard coded value like 1.2.3.4 because for local testing the value does not matter. But this is why I mentioned in one of my comments above that New-MSiPackage should be refactored to be more developer friendly.

[bergmeister]

@xee5ch I also had a look at your screenshot (tip: in Github you can just drag and drop an image into the textbox and Giyhub will integrate and host the image for you) and some other parameters are wrong as well: the productsourcepath is the publish folder that it tells you after Start-psbuild and the licencefilepath must be the path to the licence.rtf file. There is also a Readme here with examples how to call the start-psbuild beforehand

[xee5ch]

Thanks, @bergmeister, I updated the comment for posterity, since I was in a rush and I know imgur stuff goes away quickly. I was reading the help strings and had not thought much about the other docs, I should have git-grep'ed for some pointers.

I will stuff the Get-SemanticVersion function with a hard-coded value. Perhaps I will work on that when I finish this, re developer friendly. I know I need to finish this because I have been taking my sweet time.

[bergmeister]

@xee5ch Could you manage to compile the MSI in the meantime? I came home only today, so I can give you some more straightforward copy-pastable instructions to build an MSI locally for the current latest state of master. I managed to improve it so that you do not need local modifications:

powershell cd $PathToYourLocalGitRepoFolder Import-Module .\build.psm1 Start-PSBuild Import-Module .\tools\packaging\packaging.psd1 New-MSIPackage -ProductSourcePath '.\src\powershell-win-core\bin\Debug\netcoreapp2.0\win7-x64\publish' -LicenseFilePath .\assets\license.rtf -ProductVersion '6.1.0' -AssetsPath .\assets\ -ProductTargetArchitecture x64 -Force -Verbose
Please remember to update your Git repo/branch to the latest version due to recent changes (your fork is weeks behind but maybe you just haven't pushed yet?)

P.S. Do not feel pressured to finish it just because of your initial interest, I can easily finish it as well if you don't want any more for whatever reason (difficult, time, etc.). The fact that it is difficult to get started on WiX here is definitely not your fault, sorry for that for that.

[xee5ch]

Sorry I was busy yesterday. I was unable to finish before I slept and I
did not get to it before I had to step out after all. I am trying this
now.

I appreciate how persistent you are being. Apologies for my slow
response times.

On Mon, Nov 13, 2017, at 16:26, bergmeister wrote:

@xee5ch Could you manage to compile the MSI? I came home only today, so I
can give you some more straightforward copy-pastable instructions to
build an MSI locally for the current latest state of master (with bogus
versioning but for the purpose of local development and testing this does
not matter):
As I said , first replace the call to Get-PackageSemanticVersion
here
with something like 1.2.3.4:

$ProductSemanticVersion = '1.2.3.4' # Get-PackageSemanticVersion -Version
$ProductVersion

Then
powershell cd $PathToYourLocalGitRepoFolder Import-Module .\build.psm1 Start-PSBuild New-MSIPackage -ProductSourcePath '.\src\powershell-win-core\bin\Debug\netcoreapp2.0\win7-x64\publish' -LicenseFilePath .\assets\license.rtf -ProductVersion '5.6.7' -AssetsPath .\assets\ -ProductTargetArchitecture x64 -Force
Please remember to update your Git repo/branch to the latest version due
to recent changes (your forks is weeks behind but maybe you just haven't
pushed yet?)

P.S. Do not feel pressured to finish it just because of your initial
interest, I can easily finish it as well if you don't want any more for
whatever reason (difficult, time, etc.). The fact that it is difficult to
get started on WiX here is definitely not your fault, sorry for that for
that.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/PowerShell/PowerShell/issues/5012#issuecomment-344063551

[bergmeister]

@xee5ch Are you still interested/motivated in doing that (since I cannot see any work in your fork)? Do not feel pressured to do so just because you signed up for it initially. I'd be OK to finish it off myself otherwise since I myself proposed/requested this feature.

[xee5ch]

My gosh, so sorry. Yes, I shall work on this during the remainder of the weekend. Thanks for reminding me.

[bergmeister]

@xee5ch I appreciate your persistent motivation but there has simply been no progress at all in the last 3 months and there is not even a single commit or update in your fork. Since I created this issue originally because I would find this very useful, I will finish it off with a PR now. Your original intent was to learn about WiX so feel free to watch the PR and ask any question that you have. Otherwise there are still issues 5705, 5597, 5226, 2881 and 3341 open that are all to do with WiX if you really want to give it a go.

[bergmeister]

@SteveL-MSFT The PR got merged so I guess we can close this one?