Investigate alternative deployment mechanisms for Windows Terminal

[amithegde]

Having a portable version of terminal makes it easy to copy paste on machines some times on servers. Having to install from store is not convenient.

[aluhrs13]

Let me know if/when someone is looking at this. We're going down this path for WinDbg Preview, so we'll probably have some guidance on what options we looked at and pros/cons.

[jliuold]

This is an exciting feature.

[ghost]

1. Install Visual C++ Redistributable

   https://aka.ms/vs/16/release/vc_redist.x64.exe

2. Visit https://dev.azure.com/ms/Terminal/_build

3. Select most recent master build

4. Click Artifacts

5. Click appx-Release

6. Extract appx-Release.zip

7. Extract CascadiaPackage_0.0.1.0_x64.msix

8. Open WindowsTerminal.exe

Note that this does not actually work for me, the Terminal does not open.
However perhaps someone can find the missing piece from here.

[DHowett-MSFT]

What you’re missing is a local copy of the vcruntime140_app and msvcp???_app app-container runtimes. Windows Terminal should otherwise be double-click activatable.

[methodbox]

Why exactly did MS release a Terminal app that can't be used on servers, anyway?

Do you really think your primary user is only using Windows 10?

I know you guys are trying to embrace the dev and open-source worlds, but maybe ask your users what they want before releasing what would be a great tool on an environment that is less likely to be the primary user.

I'm watching this thread in hopes someone figures out how to do this; I could compile it but unfortunately installing a C++ build stack at work isn't going to happen.

[DHowett-MSFT]

@methodbox you don’t need to be unkind about it ☹️. We hear you loud and clear. We’re aware that we need a couple different distribution models.

[DHowett-MSFT]

Again, I hear you. Here’s the deal: this is a preview release, and given our available resources we have to make sure we’re investing them wisely. Letting somebody else do the distribution and installation frees up an entire month of engineering time otherwise spent building and testing an installer on all of our supported configurations. That’s why it’s on our backlog. We recognize that it’s extremely important for a huge subset of our potential users, but we are prioritizing features and performance and bug fixes first.

[methodbox]

Again, I hear you. Here’s the deal: this is a preview release, and given our available resources we have to make sure we’re investing them wisely. Letting somebody else do the distribution and installation frees up an entire month of engineering time otherwise spent building and testing an installer on all of our supported configurations. That’s why it’s on our backlog. We recognize that it’s extremely important for a huge subset of our potential users, but we are prioritizing features and performance and bug fixes first.

I guess I'm confused by that. You say that letting someone else distribute it would save time and effort, (somone else being GitHub?) yet that's not what was done first?

I wasn't being unkind, either; I was asking a serious question, and making a few serious statements.

I don't have time at work to install all the VS necessities to compile this and try to use it on Windows Server or I would, and I also don't understand the Windows 10 target audience, and I was legitimately curious if there's something I don't know that would make them the first targets.

I'm sorry criticism seems unkind, but these are legitimate concerns.

[amithegde]

• an xcopy-able exe is what is needed. Power tools like console do not need an installer. An installer is an overkill and please avoid it. Hence you don't need to spend months of testing. Last time I checked, visual studio had the capability to produce exe in release mode which is duly signed.

• as power users we are not impressed by the decision to choose store as the primary distribution model. Because, yesterday I tried to install this console at my work machine and guess what, store is configured with my Hotmail account because it needs a Microsoft account which is not my work account and I had the option to install the console on my personal PC which was at home. I needed the console on my work machine not on my personal machine.

• in summary, just simply it. Make it easy to get hold of this tool so that we can use it. Otherwise, I am happy with ConEmu which I have been using for many years.

[copdips]

Portable version is a must have for our more and more restrictive enterprise dev environment.
We dont have the admin rights on our desktops, hopefully we have vscode, pwsh, python, git, conemu, etc. in a zip version, so I would really like to see the same thing for Terminal.

[HackershubNL]

1. Install Visual C++ Redistributable
   https://aka.ms/vs/16/release/vc_redist.x64.exe
2. Visit https://dev.azure.com/ms/Terminal/_build
3. Select most recent master build
4. Click Artifacts
5. Click appx-Release
6. Extract appx-Release.zip
7. Extract CascadiaPackage_0.0.1.0_x64.msix
8. Open WindowsTerminal.exe

Note that this does not actually work for me, the Terminal does not open.
However perhaps someone can find the missing piece from here.

Instead of running WindowsTerminal.exe, you should register the application with PowerShell:
Add-AppxPackage .\AppxManifest.xml -Register

Then it shows up in the Start menu and from there you can start it.
Note, you might need to enable Developer Mode in the settings menu first, I already had it enabled so I'm not sure if it works without it.

[David-Noble-at-work]

Thanks for delivering on the developer community's need for a better terminal. This is an app I've wanted to see on Windows for years and hope to give it a spin soon. I am happy to pick up a build from master, but I'm currently on Windows Server 2019 Datacenter LTSC.

ASK:

• Support for Windows Server 2019 LTSC, Microsoft Windows NT 10.0.17763.0

• Installation instructions or a link to such instructions in README.md:

1. Install Visual C++ Redistributable (see https://aka.ms/vs/16/release/vc_redist.x64.exe)
2. Visit https://dev.azure.com/ms/Terminal/_build
3. Select most recent master build
4. Click Artifacts
5. Click appx-Release
6. Extract appx-Release.zip
7. Extract CascadiaPackage_0.0.1.0_x64.msix
8. Open WindowsTerminal.exe

[thomazmoura]

What you’re missing is a local copy of the vcruntime140_app and msvcp???_app app-container runtimes. Windows Terminal should otherwise be double-click activatable.

@DHowett-MSFT Could you please give us any guidance on how to install those?

I would love to test it on work but no chance of using Windows Store there. I tried to build it myself on an earlier version and even managed to do it, but since it took nearly 40GB between the Visual Studio requirements and the repo itself after the builds it quickly became unmanageable on my limited SSD space.

And don't mind the negative comments, by the way. The terminal is coming out nicely (really I tested it home with WSL 2 and I've never had such a smooth terminal experience on Windows before). Some people fail to understand the point of a preview but that's because they are anxiously looking forward to it too.

With time it will be out of preview and everyone (or at least most users) will be happy.

[pkzOR]

2. Visit https://dev.azure.com/ms/Terminal/_build

Non-MSFT folks dont have permissions to the artifiacts

[JongleurNin]

Same boat as Sanket. Our IT group is (understandably) very risk averse and values stability over new features. And access to Microsoft Store is blocked for security reasons, so even after we can get on a more modern build (1903, 2004), it seems we'll be unable to install Windows Terminal from MSIX packages unless we build it from source (I've done that once, but it took a long time, wouldn't want to do that every time).

Can understand the fact this is not ignored, but merely backlogged. Still, I hope it will soon be possible to deploy this via SCCM (for clients) and by some other means for Windows Server machines.

[tebeco]

@JongleurNin @sanket-bhalerao

This works fine if you have "Download" capabilities:
We stopped doing Build From source since 0.9 or 0.10 since this now works :

Manually:

• https://github.com/microsoft/terminal/releases/latest
• download msixbundle (do not execute it)
• rename to zip
• extract it
• run WindowsTerminal.exe
• pin it

Automation:

• create a pwsh function in your $PROFILE to check list-release-assets
  here you want this https://api.github.com/repos/microsoft/terminal/releases/latest
• you could use pwsh ConvertFrom-Json
• get the name property that ends with msixbundle in the asset list
• use Invoke-WebRequest on browser_download_url field
• Don't forget to use Get-Proxy and ProxyUseDefaultCredentials if you have an NTLM proxy because ... CORP ARE FUN
• use Expand-Archive pwsh function for unzip (not sure you need an explicit rename)
• put this in a Gist for your teamate ;)

[MrM40]

• an xcopy-able exe is what is needed. Power tools like console do not need an installer. An installer is an overkill and please avoid it. Hence you don't need to spend months of testing. Last time I checked, visual studio had the capability to produce exe in release mode which is duly signed.
• as power users we are not impressed by the decision to choose store as the primary distribution model. Because, yesterday I tried to install this console at my work machine and guess what, store is configured with my Hotmail account because it needs a Microsoft account which is not my work account and I had the option to install the console on my personal PC which was at home. I needed the console on my work machine not on my personal machine.
• in summary, just simply it. Make it easy to get hold of this tool so that we can use it. Otherwise, I am happy with ConEmu which I have been using for many years.

Well, I guess the only explanation for those so many non-reasonable choices in regards to installation and dependencies must be market-/political related. I guess MS want the application store to be the only legitimate source of applications (looking hungry and envious at Apple's business model), I guess it at some point make sense, but it's also a dangerous path. Windows users are not Apply users, and are not as forgiving.
I'm sure the Win Terminal team have their hands tied (well, I sure hope that is the reasons, let me put that way!)

[carwyn]

@JongleurNin @sanket-bhalerao

Manually:

* https://github.com/microsoft/terminal/releases/latest

* download `msixbundle` (do not execute it)

* rename to zip

* extract it

* run `WindowsTerminal.exe`

* pin it

Should this work with v1.1.2021.0 ?

There's no WindowsTerminal.exe in the zipfile!?

[tebeco]

you need to unzip the sub msix too
x86 / x64 / ARM
the music bundle ships all of them at once
Is that what you were wondering about ?

That was not explicit i agree

[carwyn]

you need to unzip the sub msix too

I worked this out just after I posted :) Which OSes is this expected to work on? I've tried Windows Server 2012R2 and 2016 but no luck. Not sure if I'm being overly ambitious or if there's something I need to install?

[tebeco]

You won't be able to do so, it's documented and discussed in multiple place in this repo.
WT relies on very specific feature of Windows itself which means there's a minimal version

[tebeco]

for people whilling to automate download a bit, here is a VERY NAIVE script :

• not fully test
• does not support Hot Swap if WT is running => using symlink could do Blue/green update ?
• does not Set/Update $env:PATH

[CmdletBinding()]
param (

    [Parameter()]
    [string]
    $Version = "latest",

    [Parameter()]
    [string]
    $Destination = "C:/dev/tools/wt",

    [Parameter()]
    [ValidateSet("ARM64", "x64", "x86")]
    [string]
    $Architecture = "x64"
)

function Get-WtRelease {
    [CmdletBinding()]
    param (

        [Parameter()]
        [string]
        $Version = "latest"
    )

    $GithubApi = "https://api.github.com"
    $Owner = "microsoft"
    $Repo = "Terminal"
    $ReleasesPath = "/repos/$($Owner)/$($Repo)/releases"
    $ReleasesUrl = "$($GithubApi)$($ReleasesPath)/$(Version)"
    
    $params = @{
        Uri         = $ReleasesUrl
        Method      = 'GET'
        ContentType = 'application/json'
    }
    
    $releases = Invoke-RestMethod @params

    $bundle = ($releases).assets | Where-Object { $_.name.EndsWith("msixbundle") }
    $MsixBundleDownloadUrl = $bundle.browser_download_url
    $DownloadDestination = "TEMP:\$($bundle.name).zip"
    
    Invoke-WebRequest -Uri $MsixBundleDownloadUrl -UseBasicParsing  -OutFile $DownloadDestination

    return $DownloadDestination
}

function Expand-WtMsixBundle {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [string]
        $BundlePath,

        [Parameter(Mandatory = $true)]
        [string]
        $MsixPath,

        [Parameter()]
        [ValidateSet("ARM64", "x64", "x86")]
        [string]
        $Architecture = "x64"
    )

    # $BundlePath = "C:/dev/test_wt/bundle"
    $ExtractedBundlePath = "TEMP:\expandbundle"

    if (Test-Path -PathType Container $ExtractedBundlePath) {
        Remove-Item -Recurse -Force $ExtractedBundlePath
    }

    Expand-Archive $BundlePath -DestinationPath $ExtractedBundlePath
    
    Get-ChildItem $BundlePath

    $Msix = Get-ChildItem $ExtractedBundlePath `
    | Where-Object { $_.Extension -eq ".msix" } `
    | Where-Object { $_.Name.Contains($Architecture) }

    Expand-Archive $Msix.FullName -DestinationPath $MsixPath
}

if (
    ($PSVersionTable.PSVersion.Major -lt 7) -or `
    (($PSVersionTable.PSVersion.Major -eq 7) -and ($PSVersionTable.PSVersion.Minor -lt 0)) -or `
    (($PSVersionTable.PSVersion.Major -eq 7) -and ($PSVersionTable.PSVersion.Minor -eq 0) -and ($PSVersionTable.PSVersion.Patch -lt 2)) `
) {
    throw "Powershell 7.0.2 minimal is required to use 'TEMP:', edit this script or update here: https://github.com/powershell/powershell/releases/tag/v7.0.3"
}

$MsixBundlePath = Get-WtRelease -Version $Version
Expand-WtMsixBundle -BundlePath $MsixBundlePath -MsixPath $Destination -Architecture $Architecture

[0x7FFFFFFFFFFFFFFF]

for people whilling to automate download a bit, here is a VERY NAIVE script :

* not fully test

* does not support Hot Swap if WT is running => using symlink could do Blue/green update ?

* does not Set/Update `$env:PATH`

[CmdletBinding()]
param (

    [Parameter()]
    [string]
    $Version = "latest",

    [Parameter()]
    [string]
    $Destination = "C:/dev/tools/wt",

    [Parameter()]
    [ValidateSet("ARM64", "x64", "x86")]
    [string]
    $Architecture = "x64"
)

function Get-WtRelease {
    [CmdletBinding()]
    param (

        [Parameter()]
        [string]
        $Version = "latest"
    )

    $GithubApi = "https://api.github.com"
    $Owner = "microsoft"
    $Repo = "Terminal"
    $ReleasesPath = "/repos/$($Owner)/$($Repo)/releases"
    $ReleasesUrl = "$($GithubApi)$($ReleasesPath)/$(Version)"
    
    $params = @{
        Uri         = $ReleasesUrl
        Method      = 'GET'
        ContentType = 'application/json'
    }
    
    $releases = Invoke-RestMethod @params

    $bundle = ($releases).assets | Where-Object { $_.name.EndsWith("msixbundle") }
    $MsixBundleDownloadUrl = $bundle.browser_download_url
    $DownloadDestination = "TEMP:\$($bundle.name).zip"
    
    Invoke-WebRequest -Uri $MsixBundleDownloadUrl -UseBasicParsing  -OutFile $DownloadDestination

    return $DownloadDestination
}

function Expand-WtMsixBundle {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [string]
        $BundlePath,

        [Parameter(Mandatory = $true)]
        [string]
        $MsixPath,

        [Parameter()]
        [ValidateSet("ARM64", "x64", "x86")]
        [string]
        $Architecture = "x64"
    )

    # $BundlePath = "C:/dev/test_wt/bundle"
    $ExtractedBundlePath = "TEMP:\expandbundle"

    if (Test-Path -PathType Container $ExtractedBundlePath) {
        Remove-Item -Recurse -Force $ExtractedBundlePath
    }

    Expand-Archive $BundlePath -DestinationPath $ExtractedBundlePath
    
    Get-ChildItem $BundlePath

    $Msix = Get-ChildItem $ExtractedBundlePath `
    | Where-Object { $_.Extension -eq ".msix" } `
    | Where-Object { $_.Name.Contains($Architecture) }

    Expand-Archive $Msix.FullName -DestinationPath $MsixPath
}

if (
    ($PSVersionTable.PSVersion.Major -lt 7) -or `
    (($PSVersionTable.PSVersion.Major -eq 7) -and ($PSVersionTable.PSVersion.Minor -lt 0)) -or `
    (($PSVersionTable.PSVersion.Major -eq 7) -and ($PSVersionTable.PSVersion.Minor -eq 0) -and ($PSVersionTable.PSVersion.Patch -lt 2)) `
) {
    throw "Powershell 7.0.2 minimal is required to use 'TEMP:', edit this script or update here: https://github.com/powershell/powershell/releases/tag/v7.0.3"
}

$MsixBundlePath = Get-WtRelease -Version $Version
Expand-WtMsixBundle -BundlePath $MsixBundlePath -MsixPath $Destination -Architecture $Architecture

Why forcing the use of PowerShell 7? This makes the script less useful.

[tebeco]

Hello
Thank a lot for noticing it
Do you want me to update it for you ? or do you have it already working on previous version ?
(see section Dev time bellow)

Why ?

TL;DR ? because I'm lazy and I just use things that exists out of the box

A bit of context, as I took free time trying to help, would I purposely take time to try to help by providing a non-runnable script ?
If I remember, the script uses an API that was added on 7.0 and fixed in ~7.0.2/3 so it was not intended to bother anyone
See that TEMP:\ drive

Still stuck on outdated powershell ?

Can you please provide the equivalent of what's doing the TEMP:\ drive, as said I'm lazy and I just tried to help quickly on free time
powershell is shipped only on windows and is/will be limited to 5.0 and not evolve
It's probably been ~1 year since I ran powershell TBH
Which bring us to LTS

Using LTS

in January 2018, the first edition of pwsh (PowerShell Core) was release => 6.0.0
pwsh 7.0 is the current LTS (it was shipped on the 4th March 2020)

Also as you may already know WT requires an minimal version of windows, so I might have assumed (too quickly) that consumer whilling to use wt might know about pwsh (powershell core) since v6.0 (around January 2018)

Dev time

Well, as I tend to make sure the tooling I use it up to date to avoid bugs, I did not spotted that the TEMP:\ drive was not existing on previous version of pwsh or did not even tried powershell.
This script was used by multiple teammates (may be not the very exact same script) and I think that one of them noticed the issue / updated and raised the point.
So we added a Guard to properly informed about the requirements.

I could have added input parameters about temp folder or hit CSharp API to get a Temp folder etc ...
As said, I'm lazy and a simple "if() / throw" seems to fastest way to provide a solution here

Bonus points

Also note that pwsh 7+ is running on dotnet core runtime so it is cross-platform
It makes it more useful if you need script to run on Win/Linux/MacOs
(even if WT is win only)

Updating / Installing

Did you tried to update your computer or had any trouble to do so ? How can I help about that ?

Admin right ? or not

You don't need admin right to install it

Various way

If you need help about updating your computer from either

• msix (double click)
• msixbundle (double click)
• zip (right click > extract)
• dotnet tool instal -g (copy/paste)

Official github

if you are having trouble finding it, here is the official repository
https://github.com/powershell/powershell/releases/latest

Official docs

If you prefer the docsumentation for deployement and further detailed informations:
https://github.com/powershell/powershell/releases/tag/v7.0.3

[DHowett]

@tebeco if you need an alternative to temp:/, use $Env:TEMP.

PS7> set-content temp:/file "hello"
PS7> powershell
WinPS> get-content "$Env:TEMP\file"
hello

[tebeco]

thx for the info

Do you think you would accept a PR in this repository to ship it as an asset ?
just like dotnet team release dotnet-install.ps1|sh and created an aka.ms short link

I would gladly do the PR if it's ok with you

that will fix the msixbundle issue since it's not useable so far in all enterprise env that have the store locked down

I'll probably ask

• in which folder add the file
• env variable name so that we could OR NOT default to these var if inout args are not provided
• where to change the build pipeline so that it's an individual

[DHowett]

Nope, sorry! That would imply a level of official support for this solution that we're not yet ready to agree to. Thanks though 😄

[tebeco]

I might be wrong on that, I understood that the pb was not going to be fixed in the short term as it involves other team from the Store and so on, how accurate is that do you think (~6month / ~12 maybe) ?
Also Companies locked down Store in the first place to avoid third-part installation, so they are probably not whiling to change their "Windows base image" in order to install an additional third-part (Yes Windows Terminal is a third part unless it ships within default Windows installation, which leads to the next issue of Company not updating "major image" fast (~1.5year of GAP)

To add more pain to the issue, ~70% of the time it's done (updating base image) in a part of the company that is very hard to find/contact/discuss and that will always find "good" reasons not to do what anybody else ask them to do, because they want to be sure they full own everything to be in control (... of what's installed).

When people try to install WT, they probably abandon, or try to see here, and look for solution
They probably won't be able to find a Gist/Repo somewhere else as they won't know it exists

It's kinda weird being in the middle of it

• Cannot have discussion with security locking down store / third part / windows installation
• Trying to help here to get a script doing a proper workaround, but I understand that's not your long run target (let's say in 2 years from now)

If it's possible to have a workaround starting today, until that "long run target" that's going to be releases in the next years

How far would you go to promote a solution that does workaround until something ideal is and "supportable" is released ?
Would you change the README of this repo to either/both point to a Gist/Repo hosting the script ?
Would you by default send issue open on this subject to this repo/gist script everytime somehow has the same issue ?

I'm looking for a "middle ground" that would be promoted from the Windows Terminal team, still you're not forced to have an "official support" on the source

[johan-boule]

At my company, the IT department disabled the windows store for the tens of thousands of workstation computers. Neither msixbundle nor msix files can be started from the explorer shell. For all I know, it's an alien format to our systems.
A huge number of those users would probably enjoy a better terminal.
Thanks to the person above who eventually explained we don't need all that crap and just doing a two-level-recursive unzipping to a folder of our choice actually just works fine. I honestly have no idea what's the benefit of those bundle formats that nobody knows nor want to know.

[tebeco]

It feels super weird that after almost 2 years now, there's not at least an official script proposed script or an MD workaround to have something to point user at :

Nope, sorry! That would imply a level of official support for this solution that we're not yet ready to agree to. Thanks though 😄

Yes of course it would, but just until the underlying issue is fixed, once there's an "working installer" it could just be removed right ?

Insert Diablo BlizzCon meme here
"But you all have Store, right" ?

@johan-boule
in the mean time yes, no choice double unzip.
I attempted to provide a first native script for the repo : #1386 (comment)
I understand that script is bad, but that would have been lovely to have at least this as part of this repo in the mean time

[gh4chris]

Oh my dear! Even though Chocolatey approach did somehow do the trick: I gave up. It's all far too alchemystical for me to bear from my perspective of view. For my purpose (administration) I found a solution which is far better suited: mobaXterm portable. The above is even more powerful for my daily tasks. We have a built in X-Server, a bash, serving multiple sessions (Windows, Linux, amazon, web, etc.) at once and a ton load of other goodies without all the fuzz. Just my 2c