Terminal: Investigate alternative deployment mechanisms for Windows Terminal

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.

This is an exciting feature.

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.

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.

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.

@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.

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.

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.

• 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.

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.

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.

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

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.

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

Non-MSFT folks dont have permissions to the artifiacts

I downloaded the artifacts but couldn't install the .msix by double-clicking because it said that it wasn't signed by a trusted certificate.

I've managed to get it to work by downloading the artifact, extracting the .msix to a folder and then running Add-AppxPackage AppxManifest.xml -Register from Powershell inside the folder. Now I can run it by opening if from the start menu as "Windows Terminal (Dev Build)".

Quite a hacky process, but it worked for now.

Windows store is a broken piece of software. It's like the whiny baby that always needs your attention and never does anything you expect it to do. Relying on it is as good as saying _please don't install our stuff_.

I just got redirected here from #1757 and it's good to see so much traction on this.

And why complicate a simple thing? Download, install and that should be it.

Here’s the deal: this is a preview release

Yes, and people are already excited about this. The pain of dealing with notepad of command lines (aka cmd.exe) must be maddening to drive people towards trying out a better terminal, even if it's pre-release. Plus there's twitter hype.

Please don't see our comments as rants. We _want_ to get our hands on it ASAP. Sending us to Store is slamming the door on our faces. We want to invest our time wisely too. Spending them fixing Windows store issues is definitely not a productive use of anyone's time. Hope you understand!

I'm VERY frustrated by this "install" experience. I put install in quotes because I can't actually get it to install. The Store gives me a list of some of my machines to target for the install... but not the one that I'm actually on. And even if I choose one of the listed machines, it tells me that it's trying to install, but nothing apparently ever gets installed. And there's zero feedback for me to use as a starting point for troubleshooting - no error message, or log information, just silence.

I'm bothered that there isn't just a normal installer, like we've been using for decades. And I'm bothered that the Windows Store seems to not be able to target the machine that I'm actually on (shouldn't that be a given??). With all due respect, I don't want to have to spend time troubleshooting my Windows Store environment to figure out why it doesn't acknowledge my system (and yes... it definitely meets the requirements) or why the install process seems to do absolutely nothing. I don't use the Store often, but I don't recall ever having to select a target system for the install. Is this a new feature? Either way, this experience has been terrible.

I've been a developer for 20+ years. But even I don't want to download the source for this and compile it. I just wanted a compiled executable that I can install and run.

@drullo Check your OS info. It's not so obvious but if you scroll down a little, it'll show your current vs required config. If that's the case, you'd then have to decide whether you want to risk upgrading to the current OS build or live without using the terminal.

None of this is bad in theory, but the way it's (Windows store) implemented is pretty ugly (unstable, lots of things can and will go wrong) and honestly, it's time not worth spending on just to install an app (not just terminal but any store app).

Sadly, the App store and OS updates on Mac is a whole lot smoother experience. It has its own issues but none that are at a primitive, basic level.

Please bump the priority on this one... It's probably the most asked feature...

As a first step towards alternate distribution, I've published the (signed, store updatable) MSIX bundles to the releases page. They should be double-click installable on 1903+, but there might be some dependency packages that need to be installed. We're working on making that process a little nicer. Please bear with us.

Right now, we _need_ an MSIX/appx installation context for resource lookup (icons, strings, etc.) and component activation (so that we can load our constituent DLLs), but progress is being made on making that requirement a little more lax as well.

I actually like the idea of using msix deployment. Msix has support for even Windows 7 so a double click install using msix would be great.

@DHowett-MSFT this is good start!

• I would still like portable version in the future (such as the sysinternals applications)
• Please update the readme file providing links to releases page so that people can actually notice it's available outside the Store.

@amithegde We've updated the ReadMe - thanks for your suggestion.

https://github.com/microsoft/terminal#installation

Trying to install offline using MSIX from release page, and receive the error message, upon Launching WindowsTerminal.exe CLiP device license not found. Not sure how to fix this

On offline installer is urgently needed to have the WT installed on our servers for a go.

I found this issue after several unsuccessful attempts to install Windows Terminal. The issue here is that Windows 10 LTSC (long term support version) used in many professional environements is version 1809 (build 17763), while Windows Terminal is packaged as an MSIX bundle of MSIX archives only installable on more recent versions of Windows 10.

That makes Windows Terminal unusable in professional environments in its current state. While as stated by Microsoft the next LTSC won't be released until 2021. If another deployment mechanism is not provided, Windows Terminal will remain unusable in professional environments for two more years.

I'm no Windows-centric developer, so I don't know what's the cost / burden of releasing a statically-linked exe file as a quick & dirty temporary solution, but if that's possible it would be great. Any form of standalone/portable version in fact would be greatly appreciated (as underlined by all the previous comments ;) ).

Edit:

Some additional thoughts,

• in professional environment the Windows Store is usually disabled (thus activating the developer mode and using add-appxpackage might need a clear documentation in the README in my opinion);
• it would be nice to clarify the compatibility requirements in the README (in terms of Windows 10 version needed/compatible).

@NBardelot In "professional environments" there is no way you need LTSC version of Windows and Windows Terminal together, bah, you won't need LTSC unless you are running very critical systems which I doubt.
In "professional environments" if you are required to have an application that is available from Microsoft Store, it's possible to go through the standard process of requesting stuff usually present in your company (ITIL).
Windows Terminal targets developers which are perfectly fine to have Insider version of Windows - I don't understand the argument of having it in LTSC, especially when it's in PREVIEW which contradicts with LTSC purpose.
It's very clear what you have to have in order to run it: Requirements & and Microsoft Store.

@gh4chris It's not urgently needed, CMD and PowerShell are available in Windows Server - there is no reasonable argument why you need it.

The assumption should be for any corporate adoption, that non-store usage is required. Most well built production environments have no internet access and use deployment tooling.

Why is there even resistance around convenience?

So for the record, we do provide non-store installation mechanisms - see our releases page. However, we're not really able to budge on the Windows build version requirement. We're dependent upon some OS features that only shipped in the very latest version of Windows 10. That's the real reason we won't be able to work on LTSC.

@zadjii-msft this is perfectly understandable, though I must underline again that sadly it means no Windows Terminal until 2021 for a lot of interesting use-cases (and wide adoption, once you'll be in release mode). If there's any way of working around those limitations you speak of, I hope you'll factor that into account :)

@CatTheHacker Thanks for your insights. Please also understand that telling other people that you know best what they need or not is kind of rude, since you don't have all the information available and might misunderstand the constraints. That said, I'll happily illustrate my use-case, since your misunderstanding is also my lack of explaining.

I currently work in a quite strictly secured environment, for a large company. Desktops run Windows 10 LTSC for security and maintainability reasons (and I'm not at liberty to change that). I'm not talking about critical machines/servers, but dev & ops workstations. One of our goals is to prototype and test tools that are not already streamlined in ITIL / repositories etc., and explore what can be done to make dev & ops life easier. That even brings us to compare OS vs OS tooling, which is a true paradigm shift for that kind of company. In that scenario, running a preview version of Windows Terminal, and starting to show people how to work nicely with terminals (because Powershell, docker, kubernetes/openshift...) is a need.

It would be great to have a way to automate the Windows Terminal app installation from command line.

@NBardelot - Thanks for your info & thoughts here.

MSIX

Right now, we're building Terminal into MSIX packages since this is the strategic path forward for packaging apps on Windows. We're not averse to considering other packaging formats if there's sufficient demands to do so, but for now we're focusing on mainstream scenarios to handle the majority of the community's needs.

That said, I am digging into MSIX team's plans re. LTS SKUs. Will let you know when I hear back from them.

LTS

Note that LTS SKUs are by their very definition more restricted and less-frequently updated than general release SKUs. Because of this, there's a good chance that newer products & features may take longer to arrive and/or not be supported on LTS SKUs. In short, if you want to run the latest and greatest tools & tech soon after they're released, you MAY need to consider non-LTS SKUs.

Enterprises that need greater control over the configuration of its platforms, whilst also allowing users to self-deploy approved apps, and/or deploy known managed apps might want to explore Windows Store For Business which can integrate with SCCM and InTune for automated deployment, etc. of approved apps.

We'll be updating our docs v. soon and will definitely incorporate some of your feedback & asks to make this area easier to understand.

FYI, there is now a chocolatey package, so one can run choco install microsoft-windows-terminal to install the app.

Big thanks to @mkevenaar who appears to have put that together! 🎉

@SeanKilleen Absolutely - I am a HUGE fan of Chocolatey and am grateful for @mkevenaar for creating the Chocolatey package to refer to our latest release :)

https://github.com/mkevenaar/chocolatey-packages/blob/master/automatic/microsoft-windows-terminal/update.ps1#L8

@SeanKilleen Absolutely - I am a HUGE fan of Chocolatey and am grateful for @mkevenaar for creating the Chocolatey package to refer to our latest release :)

https://github.com/mkevenaar/chocolatey-packages/blob/master/automatic/microsoft-windows-terminal/update.ps1#L8

@bitcrazed You are very welcome! It runs the update script every 6 hours, and usually it takes less then 1 hour to be processed by the chocolatey website!

[Update: Replaced prior links]:

If you are installing Windows Terminal manually, and don't have the VC Redist installed, Terminal will fail to install and/or run.

Please download and install the C++ Runtime v14 framework package for Desktop Bridge:
https://www.microsoft.com/en-us/download/details.aspx?id=53175

The C++ Runtime framework packages will be copied to a folder under %ProgramFiles(x86)%\Microsoft SDKs\Windows Kits10\ExtensionSDKs\Microsoft.VCLibs.Desktop.

👉 Note: You can also install the packages manually using the Add-AppxPackage PowerShell cmdlet.

(Related to #2369)

^ It still fails for me. It tries to install Visual C++ run-time for UWP from Store and unfortunately store is cannot access internet due to restrictions.

Event after installation from choco this message comes up:

Hey @mubaidr: I've updated my response above to link to the desktop bridge VC++ Runtime redist. Please give that a try and let me know if it solves your problem.

Still the same error message :(

Our SysAdmin disabled Windows Store and we don't have open internet connectivity. So we need an installer package.

@rfresow - we publish every publicly released Terminal build to the store and to the releases in this repo: https://github.com/microsoft/terminal/releases

⚠ Note: Since you're manually installing, do be sure to manually update regularly - we aim to publish around once a month.

@mubaidr - sorry you're bumping into issues here. Could I ask you to uninstall Terminal, reboot your machine, reinstall? I fear something unusual is going on with your machine's config.

^ @bitcrazed I am starting to think the same. Planing for fresh setup. Uninstall and reboot did not help either. So I will start with a clean setup.

FWIW, I've been running into the same VC requirements. We too have access to the Windows Store turned off for a variety of reasons (offline networks, etc.)

It would be nice to have the terminal available to install as needed on things like jump hosts, etc.

Hey @mubaidr: I've updated my response above to link to the desktop bridge VC++ Runtime redist. Please give that a try and let me know if it solves your problem.

@bitcrazed I believe the download above isn't new enough for what the terminal is built on. Mine complains about versions...

After installing the UWP VCLibs from your link, it's version 14.24222.0 (from Programs & Features) ; but if I do Get-AppXPackage:

Microsoft.VCLibs.140.00.UWPDesktop_14.0.27810.0_x64__8wekyb3d8bbwe
Microsoft.VCLibs.140.00.UWPDesktop_14.0.27810.0_x86__8wekyb3d8bbwe

The link above is dated from 2016...

The same problem - the vc_uwpdesktop.140.exe file from the link contains old versions of Microsoft.VCLibs - after you install it inC:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\Appx\ you can find:

• 14.0.24217.0 version in the "Retail" folder
• 14.0.24222.0 version in the "Debug" folder

Windows Terminal requires minimum version 14.0.27323.0. Is there any way to install it without Store enabled ?

I built (and have been using, yay) Terminal from source a few months ago with VS2019 and W10 1903. However, I don't seem to be able to execute the new msixbundle, I don't have permissions to access the Azure artifacts, and when I did a git pull and tried to rebuild in VS, I got a spew of errors even after grabbing the recommended NuGet updates and installing Dot Net 4.7.2.

Sadness :(

Windows Server 2019 Isn't supported anyway. And yes, we use only LTSB releases not because we are "reactionists". But because we work in real enterprise with over 5000 servers and even a try to update it every year is a bloody hell.

Linking all these other items to this bug is great - but it's wasting time for a lot of people who are looking to install this on Server OS. Please add a line to the project readme that says :

"Looking to install Windows Terminal on Windows Server 2019 ? - We're not there yet, come back later!..."

Linking all these other items to this bug is great - but it's wasting time for a lot of people who are looking to install this on Server OS. Please add a line to the project readme that says :

"Looking to install Windows Terminal on Windows Server 2019 ? - We're not there yet, come back later!..."

readme already states:

Note: Windows Terminal requires Windows 10 1903 (build 18362) or later

The same problem - the vc_uwpdesktop.140.exe file from the link contains old versions of Microsoft.VCLibs - after you install it inC:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\Appx\ you can find:

• 14.0.24217.0 version in the "Retail" folder
• 14.0.24222.0 version in the "Debug" folder

Windows Terminal requires minimum version 14.0.27323.0. Is there any way to install it without Store enabled ?

I'm in an environment without Microsoft Store access and have run into this issue as well. It seems the version I have installed is 14.0.26905.0. The version you get via the manual download is 14.0.24217.0. I don't see any way to get 14.0.27323.0 installed without the MS Store.

• 14.0.24217.0 version in the "Retail" folder
• 14.0.24222.0 version in the "Debug" folder

I have those versions installed and Terminal 0.6.2951.0 is running ok.

Perhaps VC 14.0.27323.0 is installed elsewhere on my system but I guess not. Where is that requirement mentioned?

• 14.0.24217.0 version in the "Retail" folder
• 14.0.24222.0 version in the "Debug" folder

I have those versions installed and Terminal 0.6.2951.0 is running ok.

Perhaps VC 14.0.27323.0 is installed elsewhere on my system but I guess not. Where is that requirement mentioned?

Does your computer have access to the MS Store? Mine does not. I recently upgraded to 1909, which may be where my version 14.0.26905.0 came from, but I'm not sure.

This is the error I get when attempting to install:

PS C:\> Add-AppPackage -path "C:\Microsoft.WindowsTerminal_0.6.2951.0_8wekyb3d8bbwe.msixbundle"
Add-AppPackage : Deployment failed with HRESULT: 0x80073CF3, Package failed updates, dependency or conflict validation.
Windows cannot install package Microsoft.WindowsTerminal_0.6.2951.0_x64__8wekyb3d8bbwe because this package depends on
a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.UWPDesktop" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor
architecture and minimum version 14.0.27323.0, along with this package to install. The frameworks with name
"Microsoft.VCLibs.140.00.UWPDesktop" currently installed are:
Windows cannot install package Microsoft.WindowsTerminal_0.6.2951.0_x64__8wekyb3d8bbwe because this package depends on
a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.UWPDesktop" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor
architecture and minimum version 14.0.27323.0, along with this package to install. The frameworks with name
"Microsoft.VCLibs.140.00.UWPDesktop" currently installed are:
{Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x86__8wekyb3d8bbwe
Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe}
NOTE: For additional information, look for [ActivityId] edfb45f8-a09f-0003-a403-fced9fa0d501 in the Event Log or use
the command line Get-AppPackageLog -ActivityID edfb45f8-a09f-0003-a403-fced9fa0d501
At line:1 char:1
+ Add-AppPackage -path "C:\Microsoft.WindowsTerminal_0.6.2951.0_8wekyb3 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Microsoft.Wi...bbwe.msixbundle:String) [Add-AppxPackage], IOException
    + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

• 14.0.24217.0 version in the "Retail" folder
• 14.0.24222.0 version in the "Debug" folder

I have those versions installed and Terminal 0.6.2951.0 is running ok.
Perhaps VC 14.0.27323.0 is installed elsewhere on my system but I guess not. Where is that requirement mentioned?

Does your computer have access to the MS Store? Mine does not. I recently upgraded to 1909, which may be where my version 14.0.26905.0 came from, but I'm not sure.

This is the error I get when attempting to install:

PS C:\> Add-AppPackage -path "C:\Microsoft.WindowsTerminal_0.6.2951.0_8wekyb3d8bbwe.msixbundle"
Add-AppPackage : Deployment failed with HRESULT: 0x80073CF3, Package failed updates, dependency or conflict validation.
Windows cannot install package Microsoft.WindowsTerminal_0.6.2951.0_x64__8wekyb3d8bbwe because this package depends on
a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.UWPDesktop" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor
architecture and minimum version 14.0.27323.0, along with this package to install. The frameworks with name
"Microsoft.VCLibs.140.00.UWPDesktop" currently installed are:
Windows cannot install package Microsoft.WindowsTerminal_0.6.2951.0_x64__8wekyb3d8bbwe because this package depends on
a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.UWPDesktop" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor
architecture and minimum version 14.0.27323.0, along with this package to install. The frameworks with name
"Microsoft.VCLibs.140.00.UWPDesktop" currently installed are:
{Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x86__8wekyb3d8bbwe
Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe}
NOTE: For additional information, look for [ActivityId] edfb45f8-a09f-0003-a403-fced9fa0d501 in the Event Log or use
the command line Get-AppPackageLog -ActivityID edfb45f8-a09f-0003-a403-fced9fa0d501
At line:1 char:1
+ Add-AppPackage -path "C:\Microsoft.WindowsTerminal_0.6.2951.0_8wekyb3 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Microsoft.Wi...bbwe.msixbundle:String) [Add-AppxPackage], IOException
    + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

I recently upgraded another PC in this same environment to 1909. I was able to install the latest Windows Terminal 0.6.2951.0. Turns out, this machine has UWPDesktop v 14.0.27810.0. I'm not 100% sure where, when, or how it got installed, though I think it may be because this machine has VS2017 and VS2019 installed.

It seems like what needs to happen is to have this download
https://www.microsoft.com/en-us/download/details.aspx?id=53175
updated to be version 14.0.27810.0 (or later). I'm not sure why that download has stagnated since 2016.

Update: We're having some conversations internally to resolve this issue. Stay tuned.

FWIW, I work on environments that will never be internet connected. Certifications that Azure, M365, etc. have received be-damned. They will simply never have internet connectivity.

Windows Terminal has been available in Scoop. Scoop extracts files from msix with 7zip and it works well. So I guess Windows Terminal is already portable? It seems not all msix installer can work as this.

It is true today that Terminal works unpackaged, but we are not currently guaranteeing that it always will.

Using chocolatey fails on windows server 2019:

choco install microsoft-windows-terminal
ERROR: This package requires at least Windows 10 version 1903/OS build 18362.x.
The install of microsoft-windows-terminal was NOT successful.

Is there diffrent versions of windows server or are all of them too old?

@ArgTang I believe none of the Server versions are available: https://github.com/microsoft/terminal/issues/2312#issuecomment-519318609

Indeed! /dup #2312.

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

Right now, Server isn't available in 1903 or 1909 flavors. Sorry about that!

I absolutely didn't mean to close this master tracking bug. Sorry everyone!

So far i found absolutly no workaround at work either
as previous issue was closed, i'm updating here with the latest released version :
(copy pasting previous issue here not to loose track from #4424, sorry @DHowett i think this is helpfull to see the behavior of each released version has it changed time to time)

result is here : https://github.com/microsoft/terminal/issues/4424 issue was closed in favor of this one

The only version working i have is 0.6xxxx that i manually built, i have mdmerge.exe crash when attempting to build 0.8.x on either 19041 slow ring or on 1909 stable

Copy paste from closed issue :

The last WindowsTerminal_0.8.10261.0_x64__8wekyb3d8bbwe msixbundle does install but the app crash, same if i install from chocolatey

@DHowett

Thx for the improuvment over the msixbundle as it not install, and start to run.
Can you tell me how i can get info on WHY it crash when running so I can create a proper issue for potentially addressing it in later version ?

I can see the border appear for half a second, then crash and this :

if i open fast enought the Start Menu i can see that there is probably some sort of MS Store Post Action (the progress bar):

How can i help ?
I wonder where the Logs are to diagnose this.
I not sure where to look at in the EventViewer (i tried to check but did not found anything that look like the crash)

[Window Title]
Network Error

[Main Instruction]
Windows cannot access C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.8.10261.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe

[Content]
Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.

[^] Hide details  [Diagnose] [Cancel]

[Expanded Information]
Error code: 0x800704cf
The network location cannot be reached. For information about network troubleshooting, see Windows Help.

If in any way the current installation state can help, let me know.

I did not found a way yet to get logs/diag/trace on what is not found so it can helps gives feedback on this specific behavior to see if and how it could potentially be fixed ^^

I dont mind not having "Store update" since ... Corporation lock down the store.
that's why for now i try to use the msixbundle at least once ;)
I would just re-install next msixbundle when i need to update

Thanks everyone for your patience with this matter.

We fully understand what's going on here, but don't want to deliver a hacky solution.

We are actively working with several teams internally to deliver a long-term supportable solution to this problem and will report back here once we know what can be done and when. In fact, I filed a formal ask about 20 mins ago for another team to do a little work for us.

Stay tuned.

Sorry @iamdeskoh - deleting this comment as it recommends downloading packages from an unverified, untrusted source. Such practices are absolutely not recommended. We'd hate for someone to inadvertently get infected with something nasty by doing so.

Rest assured we're chasing things down internally to fix this issue. Please be patient with us.

@bitcrazed

nop, won't click that link

why would i attempt to click an unknown / un trusted domain ?
especially to install binaries from an unofficial source

you may first want to explain what is the purpose of the website before sending a link and ask for user to click it. also i suppose what it does behind the site is open source so that it could be trusted ^^ ?

i'm not saying it does not work, just that there's no way you could trust a third part shipping magic binaries
Especially when you could first ask here to windows/terminal team if they might be able to address it

I don't like this workaround too much either, but the download links come from the Microsoft domain. It seems the website @deskoh provided just provides links to unlisted content from the Microsoft Store.
And if the team could provide a way to install the required dependencies for their project, people would not have to try their luck with workaround like this...
But even after installing the recent-enough version of Microsoft.VCLibs.140.00.UWPDesktop, the installation still fails later on due to another error.

@clement-fischer what errors did you encounter? I finally managed to run it in an air gap environment. You will need VC++ redistributable. I also have to launch the terminal from WindowsApp directory.

@deskoh Although I tried to install via Powershell, the error seems to be the same as in #3194.

I have tried several methods to install the msix and appx manually, and the Windows Terminal builds appear to be locked to Windows 10 versions more recent than the most recent Windows Server 2019 build.

This is quite unfortunate.

Sadly for all of us, this feature will not be presented in Terminal 1.0 release. So, Terminal still will be useless for IT Pros in real production environments: https://github.com/microsoft/terminal/milestone/6

If they fix the availability of the dependency, then it should be possible to install manually. Issue #3097 is listed as one of the required issues for 1.0.

I can't tell for other users, but i would very much love having the msixbundle working anywhere, even if it means i have to update it myself later.
That's how i use Powershell Core 7.x at work since the first preview.

On top of that there's a nice message informing you INSIDE the shell (so not intrusive) that you are missing an update.
I think there's also an opt-out on it

What would be way better that extracting the msixbundle manually for example

works well with scoop, we can used it in pro environment. (from our pro windows desktop):
https://github.com/lukesampson/scoop-extras/blob/master/bucket/windows-terminal.json
scoop install windows-terminal

Thanks for this!

scoop is the coolest thing evr!
https://youtu.be/a85QLUJ0Wbs

It's such a nice and useful tool, feels like home

Am Fr., 24. Apr. 2020 um 12:03 Uhr schrieb Xiang ZHU <
[email protected]>:

Well, still not useable for Windows Server environment:

iwr -useb get.scoop.sh | iex
Set-ExecutionPolicy RemoteSigned -scope CurrentUser
scoop install git
scoop bucket add bucket extras
scoop install windows-terminal
Installing 'windows-terminal' (0.11.1121.0) [64bit]
Microsoft.WindowsTerminal_0.11.1121.0_8wekyb3d8bbwe.msixbundle (16,1 MB)
[====================================] 100%
Checking hash of
Microsoft.WindowsTerminal_0.11.1121.0_8wekyb3d8bbwe.msixbundle ... ok.
Extracting dl.7z ... done.
Running pre-install script...
Running installer script...
*ERROR At least Windows 10 18362 is required. *

@gh4chris
Same on Desktop right ?
As the terminal rely on specific Feature from the OS, it requires a certain minimum version level

You probably want to update to 1903 / 1909 (2004/20H1 is supposed to Land in less than a month)

You see? That's problematic in a professional environment. Updates involve
a lot of verification not to break the existing setups...

I doubt that WT really needs such dependencies. IT makes the whole project
more or less ridiculous

Am Fr., 24. Apr. 2020 um 13:10 Uhr schrieb TeBeCo <[email protected]

I understand you have issue updating your servers in your company, that's a different isue unrelated to deployment.
You may want to contact teams on your side to update their image to get at least the one from one years ago.

That's a bit different than "There are no alternative to the store yet"

I would not say that it's blocking or problematic. You can for example use Enter-PSSession or ssh and then you would be using WT from your computer while you use the Shell of the Server
You could even update to PSWS 7.x on your server if you'd like, or install it as a dotnet tool

You probably want to open another issue than Investigate alternative deployment mechanisms for Windows Terminal

I really don't want to get into the argument brewing in here about what constitutes a 'real environment'

But I certainly would like this to run on Windows Server (any version), and having it run on Windows 10 is not useful in my circumstance either.

I would just say to update to Windows Server 2019
but that could be a hard pill to swallow as even Azure portal does not offer template for it
(but yeah, i suppose "just update")

also, as i'm just a consumer like you, can you open an issue for that as it's unrelated to this one ?
Maybe ask there why and details about the minimum OS version
but it's not related to deployment mechanism

Hey @DHowett , your commit (that I know hasn't been released yet) to bundle the deps into terminal should help a lot with having an offline msixbundle installer.

It seems like after that, the main missing piece for a sane offline installation method is have an aka.ms static URL to download the latest msixbundle from, rather than having to keep your scripts up-to-date with the latest github.com release and download URL.

Is it possible to get a static download link for this bundle going?

Is it possible to get a static download link for this bundle going?

That's not a bad idea, and it's probably something we'll need to do sooner rather than later.

I'd prefer to offer an appinstaller (which is pretty much a msixbundle with a "where do I find more of you?" tag (for updates!)), but that actually requires this so _shrug_.

*ERROR At least Windows 10 18362 is required. *

Why is there such weird hard requirement? Can't dependency on this be lowered so it can be usable on LTSC versions?

@kein That's something we've discussed on this repo at length before.

#1643 (comment)

Sorry. Right now, there's two big blockers to adoption on 1809.

* XAML islands was a technology preview and didn't support high-DPI, DPI changes, or accessibility in 1809. We rely on them heavily.

* 1903 added support for side-by-side WinRT component activation, something deep in the COM stack that lets us find our DLLs when they're right next to our EXE.

We just can't go back to 1809.

#1909 (comment)

the Windows Terminal REQUIRES features from the latest Windows release.

Unfortunately, there's really no workarounds available to us. XAML Islands is the technology we use to host our XAML UI in a Win32 process. Without that, we'd be unable to display anything. Since XAML Islands is only complete as of the latest Windows 10 release, there's nothing we can do about it.
If you'll want to use the terminal, you'll _need_ to be on the latest Windows 10 version.

#841 (comment)

#498 (comment)

There are no plans currently.
We're dependent upon C++/WinRT and XAML Islands (UWP XAML) for our UI. We're also using DX/DWrite for the text renderer. Unless those are ported to linux sometime, then I'd say there's very little chance we ever support linux.
Furthermore, our entire build system is MsBuild-based, and I could be wrong, but I don't think our build system will work on linux.

#1893 (comment)

#2024 (comment)

This explains why support such limited but does not invalidate any of the arguments raise here. Majority of users for Terminal are Server and LTSC users. What the point of Terminal targeting home users? Eventually it will fade away being locked to a very specific environment. Right now I;m back to cmder and unless Terminal will be manage to overcome this issue and be available sooner in 2020 I will forget about it as well.

Majority of users for Terminal are Server and LTSC users

Do you have any evidence for that statement?

Can this issue be divided into 2 issues; alternative deployment mechanism and minimum version?

There's plenty of other threads regarding "min version", so I'm gonna just start marking discussion about the min version in this thread as "off topic".

Our use case: A University that is running a longer term support branch on 3.5k Windows 10 desktops, they do have the Windows store enabled so they can get Terminal. Our admins (the ones that would really like and benefit from Terminal) do have Windows workstations that they can use it on, but for the most part are using RDP into many heterogeneous Windows servers running mostly Server 2016 to then use MMC and PowerShell to configure them. Terminal would be great to have on all of these.

The other usage pattern is to RDP to a single bastion Windows Remote Desktop Server to then interact with the other servers via Enter-PSSession.

We have very few Windows Core servers as the third party applications stacks and consultants that regularly come with them for initial deployment don't understand it or the applications don't support it.

We have a configuration management platform that we use to ship mainly MSIs to both Windows 10 and Server 2016 so shipping it everywhere would be easy, if it was in a format that would work.

@carwyn same here. Our environment tend to have n-1 so the client we support just upgraded to 2016.

I have previewed windows terminal on a desktop in my own machine at home and love it. I would love to use it 'in production' on our jump boxes at work for the team to use but with the only option to windows server 2019 means we have will have to wait a lot longer which is a bit disappointing for an amazing client that I can potentially use to replace my aging windows powershell ise.

Sorry guys, I'm not happy with all the limitations and difficulties with
the installations.
I guess I found my solution. I'm using mobaXterm now. It got almost all
features I need and just needs to run the installer.
Life can be easy

Am Do., 11. Juni 2020 um 10:20 Uhr schrieb weiyentan <
[email protected]>:

None of the solutions mentioned here worked for me for installing on Windows Server 2019. Even with scoop it fails with "ERROR At least Windows 10 18362 is required."

None of the solutions mentioned here worked for me for installing on Windows Server 2019. Even with scoop it fails with "ERROR At least Windows 10 18362 is required."

Correct. It won’t work on Server 2019. 2019 is based on 1809. And at least 1903 is needed.

None of the solutions mentioned here worked for me for installing on Windows Server 2019. Even with scoop it fails with "ERROR At least Windows 10 18362 is required."

Also you can take a look at the last comment in this issue:
https://github.com/microsoft/terminal/issues/1386#issuecomment-634933002

Hi @DHowett , regarding #6802
downloading and double-clicking on the package does not install the Microsoft Terminal if the Microsoft store access is restricted. it shows the following error

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.

@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 ;)

• 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!)

@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!?

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

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?

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

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

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.

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

@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

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

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

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