Investigate alternative deployment mechanisms for Windows Terminal #1846

@aluhrs13 commented on GitHub (Jun 22, 2019):

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.

@aluhrs13 commented on GitHub (Jun 22, 2019): 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.

claunia commented

@jliuold commented on GitHub (Jun 22, 2019):

This is an exciting feature.

@jliuold commented on GitHub (Jun 22, 2019): This is an exciting feature.

claunia commented

@ghost commented on GitHub (Jun 22, 2019):

Install Visual C++ Redistributable

https://aka.ms/vs/16/release/vc_redist.x64.exe
Visit https://dev.azure.com/ms/Terminal/_build
Select most recent master build
Click Artifacts
Click appx-Release
Extract appx-Release.zip
Extract CascadiaPackage_0.0.1.0_x64.msix
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.

@ghost commented on GitHub (Jun 22, 2019): 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.

claunia commented

@DHowett-MSFT commented on GitHub (Jun 22, 2019):

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 commented on GitHub (Jun 22, 2019): 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.

claunia commented

@methodbox commented on GitHub (Jun 22, 2019):

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 commented on GitHub (Jun 22, 2019): 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.

claunia commented

@DHowett-MSFT commented on GitHub (Jun 22, 2019):

@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 commented on GitHub (Jun 22, 2019): @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.

claunia commented

@DHowett-MSFT commented on GitHub (Jun 22, 2019):

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.

@DHowett-MSFT commented on GitHub (Jun 22, 2019): 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.

claunia commented

@methodbox commented on GitHub (Jun 22, 2019):

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.

@methodbox commented on GitHub (Jun 22, 2019): > 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.

claunia commented

@amithegde commented on GitHub (Jun 22, 2019):

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.

@amithegde commented on GitHub (Jun 22, 2019): - 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.

claunia commented

@copdips commented on GitHub (Jun 23, 2019):

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.

@copdips commented on GitHub (Jun 23, 2019): 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.

claunia commented

@HackershubNL commented on GitHub (Jun 24, 2019):

Install Visual C++ Redistributable
https://aka.ms/vs/16/release/vc_redist.x64.exe

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

Select most recent master build

Click Artifacts

Click appx-Release

Extract appx-Release.zip

Extract CascadiaPackage_0.0.1.0_x64.msix

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.

@HackershubNL commented on GitHub (Jun 24, 2019): > 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.

claunia commented

@David-Noble-at-work commented on GitHub (Jun 25, 2019):

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:

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

@David-Noble-at-work commented on GitHub (Jun 25, 2019): 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

claunia commented

@thomazmoura commented on GitHub (Jun 25, 2019):

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.

@thomazmoura commented on GitHub (Jun 25, 2019): > 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.

claunia commented

@pkzOR commented on GitHub (Jun 27, 2019):

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

Non-MSFT folks dont have permissions to the artifiacts

@pkzOR commented on GitHub (Jun 27, 2019): > 2\. Visit https://dev.azure.com/ms/Terminal/_build Non-MSFT folks dont have permissions to the artifiacts

claunia commented

@thomazmoura commented on GitHub (Jun 27, 2019):

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.

@thomazmoura commented on GitHub (Jun 27, 2019): 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.

claunia commented

@mrchief commented on GitHub (Jul 1, 2019):

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.

@mrchief commented on GitHub (Jul 1, 2019): 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.

claunia commented

@mrchief commented on GitHub (Jul 1, 2019):

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!

@mrchief commented on GitHub (Jul 1, 2019): > 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!

claunia commented

@drullo commented on GitHub (Jul 2, 2019):

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 commented on GitHub (Jul 2, 2019): 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.

claunia commented

@mrchief commented on GitHub (Jul 2, 2019):

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

@mrchief commented on GitHub (Jul 2, 2019): @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.

claunia commented

@VimalShekar commented on GitHub (Jul 9, 2019):

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

@VimalShekar commented on GitHub (Jul 9, 2019): Please bump the priority on this one... It's probably the most asked feature...

claunia commented

@DHowett-MSFT commented on GitHub (Jul 10, 2019):

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.

@DHowett-MSFT commented on GitHub (Jul 10, 2019): As a first step towards alternate distribution, I've published the (signed, store updatable) MSIX bundles to the [releases page](https://github.com/microsoft/terminal/releases). 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.

claunia commented

@WSLUser commented on GitHub (Jul 12, 2019):

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.

@WSLUser commented on GitHub (Jul 12, 2019): 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.

claunia commented

@amithegde commented on GitHub (Jul 13, 2019):

@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 commented on GitHub (Jul 13, 2019): @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.

claunia commented

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

@bitcrazed commented on GitHub (Jul 30, 2019):

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

@bitcrazed commented on GitHub (Jul 30, 2019): @amithegde We've updated the ReadMe - thanks for your suggestion. https://github.com/microsoft/terminal#installation

claunia commented

@rismoney commented on GitHub (Aug 2, 2019):

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

@rismoney commented on GitHub (Aug 2, 2019): 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

claunia commented

@gh4chris commented on GitHub (Aug 5, 2019):

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

@gh4chris commented on GitHub (Aug 5, 2019): On offline installer is urgently needed to have the WT installed on our servers for a go.

claunia commented

@NBardelot commented on GitHub (Aug 6, 2019):

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 commented on GitHub (Aug 6, 2019): 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).

claunia commented

@catthehacker commented on GitHub (Aug 6, 2019):

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

@catthehacker commented on GitHub (Aug 6, 2019): @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](https://github.com/microsoft/terminal#i-tried-running-windowsterminalexe-and-it-crashes) & 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.

claunia commented

@rismoney commented on GitHub (Aug 6, 2019):

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?

@rismoney commented on GitHub (Aug 6, 2019): 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?

claunia commented

@zadjii-msft commented on GitHub (Aug 6, 2019):

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 commented on GitHub (Aug 6, 2019): So for the record, we do provide non-store installation mechanisms - see our [releases](https://github.com/microsoft/terminal/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.

claunia commented

@NBardelot commented on GitHub (Aug 9, 2019):

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

@NBardelot commented on GitHub (Aug 9, 2019): @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.

claunia commented

@TechWatching commented on GitHub (Aug 19, 2019):

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

@TechWatching commented on GitHub (Aug 19, 2019): It would be great to have a way to automate the Windows Terminal app installation from command line.

claunia commented

@bitcrazed commented on GitHub (Aug 21, 2019):

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

@bitcrazed commented on GitHub (Aug 21, 2019): @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.

claunia commented

@SeanKilleen commented on GitHub (Sep 1, 2019):

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 commented on GitHub (Sep 1, 2019): FYI, there is now [a chocolatey package](https://chocolatey.org/packages/microsoft-windows-terminal/), so one can run `choco install microsoft-windows-terminal` to install the app. Big thanks to @mkevenaar who appears to have put that together! 🎉

claunia commented

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

@bitcrazed commented on GitHub (Sep 4, 2019):

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

@bitcrazed commented on GitHub (Sep 4, 2019): @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

claunia commented

@mkevenaar commented on GitHub (Sep 4, 2019):

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

@mkevenaar commented on GitHub (Sep 4, 2019): > @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!

claunia commented

@bitcrazed commented on GitHub (Sep 27, 2019):

[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 Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.

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

(Related to #2369)

@bitcrazed commented on GitHub (Sep 27, 2019): [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 Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop. 👉 Note: You can also install the packages manually using the Add-AppxPackage PowerShell cmdlet. (Related to #2369)

claunia commented

@mubaidr commented on GitHub (Oct 3, 2019):

^ 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:

@mubaidr commented on GitHub (Oct 3, 2019): ^ 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: ![Capture](https://user-images.githubusercontent.com/2222702/66104656-2ae00b00-e56e-11e9-98b5-4c79f7a1460d.PNG)

claunia commented

@bitcrazed commented on GitHub (Oct 8, 2019):

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 commented on GitHub (Oct 8, 2019): Hey @mubaidr: I've updated [my response above](https://github.com/microsoft/terminal/issues/1386#issuecomment-535764329) to link to the desktop bridge VC++ Runtime redist. Please give that a try and let me know if it solves your problem.

claunia commented

@mubaidr commented on GitHub (Oct 9, 2019):

Still the same error message :(

@mubaidr commented on GitHub (Oct 9, 2019): Still the same error message :( ![Capture](https://user-images.githubusercontent.com/2222702/66454101-87827080-ea1b-11e9-836c-be3ce2f78370.PNG)

claunia commented

@rfresow commented on GitHub (Oct 10, 2019):

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

@rfresow commented on GitHub (Oct 10, 2019): Our SysAdmin disabled Windows Store and we don't have open internet connectivity. So we need an installer package.

claunia commented

@bitcrazed commented on GitHub (Oct 11, 2019):

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

@bitcrazed commented on GitHub (Oct 11, 2019): @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.

claunia commented

@bitcrazed commented on GitHub (Oct 11, 2019):

@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 commented on GitHub (Oct 11, 2019): @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.

claunia commented

@mubaidr commented on GitHub (Oct 11, 2019):

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

@mubaidr commented on GitHub (Oct 11, 2019): ^ @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.

claunia commented

@miketheitguy commented on GitHub (Oct 13, 2019):

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.

@miketheitguy commented on GitHub (Oct 13, 2019): 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.

claunia commented

@miketheitguy commented on GitHub (Oct 13, 2019):

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

@miketheitguy commented on GitHub (Oct 13, 2019): > Hey @mubaidr: I've updated [my response above](https://github.com/microsoft/terminal/issues/1386#issuecomment-535764329) 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...

claunia commented

@RafneQ commented on GitHub (Oct 23, 2019):

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 ?

@RafneQ commented on GitHub (Oct 23, 2019): The same problem - the `vc_uwpdesktop.140.exe` file from the [link ](https://github.com/microsoft/terminal/issues/1386#issuecomment-535764329)contains old versions of Microsoft.VCLibs - after you install it in` C:\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 ?

claunia commented

@mikepurvis commented on GitHub (Nov 7, 2019):

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 :(

@mikepurvis commented on GitHub (Nov 7, 2019): 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 :(

claunia commented

@ertyz commented on GitHub (Nov 11, 2019):

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.

@ertyz commented on GitHub (Nov 11, 2019): 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.

claunia commented

@VimalShekar commented on GitHub (Nov 15, 2019):

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!..."

@VimalShekar commented on GitHub (Nov 15, 2019): 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!..."

claunia commented

@amithegde commented on GitHub (Nov 19, 2019):

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

@amithegde commented on GitHub (Nov 19, 2019): > 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`

claunia commented

@oryandunn commented on GitHub (Nov 21, 2019):

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.

@oryandunn commented on GitHub (Nov 21, 2019): > The same problem - the `vc_uwpdesktop.140.exe` file from the [link ](https://github.com/microsoft/terminal/issues/1386#issuecomment-535764329)contains old versions of Microsoft.VCLibs - after you install it in`C:\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.

claunia commented

@daldr-ntml commented on GitHub (Nov 22, 2019):

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?

@daldr-ntml commented on GitHub (Nov 22, 2019): - 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?

claunia commented

@oryandunn commented on GitHub (Nov 22, 2019):

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

@oryandunn commented on GitHub (Nov 22, 2019): > * 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 ```

claunia commented

@oryandunn commented on GitHub (Nov 25, 2019):

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.

@oryandunn commented on GitHub (Nov 25, 2019): > > > > * 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.

claunia commented

@bitcrazed commented on GitHub (Nov 25, 2019):

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

@bitcrazed commented on GitHub (Nov 25, 2019): Update: We're having some conversations internally to resolve this issue. Stay tuned.

claunia commented

@miketheitguy commented on GitHub (Nov 26, 2019):

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.

@miketheitguy commented on GitHub (Nov 26, 2019): 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.

claunia commented

@linsui commented on GitHub (Jan 9, 2020):

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.

@linsui commented on GitHub (Jan 9, 2020): Windows Terminal has been available in [Scoop](https://github.com/lukesampson/scoop-extras/blob/master/bucket/windows-terminal.json). 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.

claunia commented

@DHowett-MSFT commented on GitHub (Jan 9, 2020):

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

@DHowett-MSFT commented on GitHub (Jan 9, 2020): It is true today that Terminal works unpackaged, but we are not currently guaranteeing that it always will.

claunia commented

@ArgTang commented on GitHub (Jan 13, 2020):

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 commented on GitHub (Jan 13, 2020): 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. ![image](https://user-images.githubusercontent.com/8416172/72241659-aa5a8d00-35e7-11ea-9a01-a173f71cac15.png) Is there diffrent versions of windows server or are all of them too old?

claunia commented

@mkevenaar commented on GitHub (Jan 13, 2020):

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

@mkevenaar commented on GitHub (Jan 13, 2020): @ArgTang I believe none of the Server versions are available: https://github.com/microsoft/terminal/issues/2312#issuecomment-519318609

claunia commented

@DHowett-MSFT commented on GitHub (Jan 13, 2020):

Indeed! /dup #2312.

@DHowett-MSFT commented on GitHub (Jan 13, 2020): Indeed! /dup #2312.

claunia commented

@ghost commented on GitHub (Jan 13, 2020):

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!

@ghost commented on GitHub (Jan 13, 2020): 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!

claunia commented

@DHowett-MSFT commented on GitHub (Jan 13, 2020):

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

@DHowett-MSFT commented on GitHub (Jan 13, 2020): Right now, Server isn't available in 1903 or 1909 flavors. Sorry about that!

claunia commented

@DHowett-MSFT commented on GitHub (Jan 13, 2020):

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

@DHowett-MSFT commented on GitHub (Jan 13, 2020): I absolutely didn't mean to close this master tracking bug. Sorry everyone!

claunia commented

@tebeco commented on GitHub (Feb 7, 2020):

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.

@tebeco commented on GitHub (Feb 7, 2020): 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 : ![image](https://user-images.githubusercontent.com/2266487/73839990-828dcc00-4817-11ea-8195-f74f7cc91993.png) 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): ![image](https://user-images.githubusercontent.com/2266487/73840495-8e2dc280-4818-11ea-82c6-22c797d9e39b.png) 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. ```

claunia commented

@tebeco commented on GitHub (Feb 7, 2020):

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

@tebeco commented on GitHub (Feb 7, 2020): 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

claunia commented

@bitcrazed commented on GitHub (Feb 8, 2020):

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.

@bitcrazed commented on GitHub (Feb 8, 2020): 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.

claunia commented

@deskoh commented on GitHub (Feb 26, 2020):

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

@deskoh commented on GitHub (Feb 26, 2020): 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

claunia commented

@tebeco commented on GitHub (Feb 26, 2020):

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

@tebeco commented on GitHub (Feb 26, 2020): **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

claunia commented

@clement-fischer commented on GitHub (Feb 26, 2020):

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 commented on GitHub (Feb 26, 2020): 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.

claunia commented

@deskoh commented on GitHub (Feb 26, 2020):

@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 commented on GitHub (Feb 26, 2020): @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.

claunia commented

@clement-fischer commented on GitHub (Feb 27, 2020):

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

@clement-fischer commented on GitHub (Feb 27, 2020): @deskoh Although I tried to install via Powershell, the error seems to be the same as in #3194.

claunia commented

@XenHat commented on GitHub (Apr 3, 2020):

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.

@XenHat commented on GitHub (Apr 3, 2020): 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.

claunia commented

@ertyz commented on GitHub (Apr 23, 2020):

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

@ertyz commented on GitHub (Apr 23, 2020): 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

claunia commented

@oryandunn commented on GitHub (Apr 24, 2020):

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.

@oryandunn commented on GitHub (Apr 24, 2020): 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.

claunia commented

@tebeco commented on GitHub (Apr 24, 2020):

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

@tebeco commented on GitHub (Apr 24, 2020): 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

claunia commented

@copdips commented on GitHub (Apr 24, 2020):

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

@copdips commented on GitHub (Apr 24, 2020): 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`

claunia commented

@gh4chris commented on GitHub (Apr 24, 2020):

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 <
notifications@github.com>:

@gh4chris commented on GitHub (Apr 24, 2020): 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 < notifications@github.com>:

claunia commented

@gh4chris commented on GitHub (Apr 24, 2020):

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 commented on GitHub (Apr 24, 2020): *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. *

claunia commented

@tebeco commented on GitHub (Apr 24, 2020):

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

@tebeco commented on GitHub (Apr 24, 2020): @gh4chris Same on Desktop right ? As the terminal rely on specific Feature from the OS, it requires a certain minimum version level ![image](https://user-images.githubusercontent.com/2266487/80206649-0001f500-862d-11ea-9c99-13ae3fb5a460.png) You probably want to update to 1903 / 1909 (2004/20H1 is supposed to Land in less than a month) ![image](https://user-images.githubusercontent.com/2266487/80206554-cdf09300-862c-11ea-8f9a-ed082dc07d19.png)

claunia commented

@gh4chris commented on GitHub (Apr 24, 2020):

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 <notifications@github.com

@gh4chris commented on GitHub (Apr 24, 2020): 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 <notifications@github.com

claunia commented

@tebeco commented on GitHub (Apr 24, 2020):

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

@tebeco commented on GitHub (Apr 24, 2020): 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`

claunia commented

@bjtucker commented on GitHub (May 1, 2020):

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.

@bjtucker commented on GitHub (May 1, 2020): 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.

claunia commented

@tebeco commented on GitHub (May 1, 2020):

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

@tebeco commented on GitHub (May 1, 2020): 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

claunia commented

@holtwilkins commented on GitHub (May 4, 2020):

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?

@holtwilkins commented on GitHub (May 4, 2020): 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?

claunia commented

@DHowett-MSFT commented on GitHub (May 5, 2020):

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.

@DHowett-MSFT commented on GitHub (May 5, 2020): > 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_.

claunia commented

@Kein commented on GitHub (May 26, 2020):

*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 commented on GitHub (May 26, 2020): > *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?

claunia commented

@zadjii-msft commented on GitHub (May 26, 2020):

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

@zadjii-msft commented on GitHub (May 26, 2020): @kein That's something [we've discussed on this repo at length before](https://github.com/microsoft/terminal/issues/2480#issuecomment-523020964). > ### [#1643 (comment)](https://github.com/microsoft/terminal/issues/1643#issuecomment-505971691) > > > 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)](https://github.com/microsoft/terminal/issues/1909#issuecomment-510042323) > > > > 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)](https://github.com/microsoft/terminal/issues/841#issuecomment-492940388) > ### [#498 (comment)](https://github.com/microsoft/terminal/issues/498#issuecomment-490091740) > > > 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)](https://github.com/microsoft/terminal/issues/1893#issuecomment-509728952) > ### [#2024 (comment)](https://github.com/microsoft/terminal/issues/2024#issuecomment-512788360)

claunia commented

@Kein commented on GitHub (May 27, 2020):

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.

@Kein commented on GitHub (May 27, 2020): 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.

claunia commented

@zadjii-msft commented on GitHub (May 27, 2020):

Majority of users for Terminal are Server and LTSC users

Do you have any evidence for that statement?

@zadjii-msft commented on GitHub (May 27, 2020): > Majority of users for Terminal are Server and LTSC users Do you have any evidence for that statement?

claunia commented

@sozercan commented on GitHub (May 27, 2020):

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

@sozercan commented on GitHub (May 27, 2020): Can this issue be divided into 2 issues; alternative deployment mechanism and minimum version?

claunia commented

@zadjii-msft commented on GitHub (May 27, 2020):

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

@zadjii-msft commented on GitHub (May 27, 2020): 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".

claunia commented

@carwyn commented on GitHub (May 27, 2020):

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 commented on GitHub (May 27, 2020): 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.

claunia commented

@weiyentan commented on GitHub (Jun 11, 2020):

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

@weiyentan commented on GitHub (Jun 11, 2020): @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.

claunia commented

@gh4chris commented on GitHub (Jun 11, 2020):

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 <
notifications@github.com>:

@gh4chris commented on GitHub (Jun 11, 2020): 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 < notifications@github.com>:

claunia commented

@omidkrad commented on GitHub (Jun 28, 2020):

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

@omidkrad commented on GitHub (Jun 28, 2020): 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."

claunia commented

@miketheitguy commented on GitHub (Jun 28, 2020):

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](tel:10 18362) is required."

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

@miketheitguy commented on GitHub (Jun 28, 2020): > 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](tel:10 18362) is required." Correct. It won’t work on Server 2019. 2019 is based on 1809. And at least 1903 is needed.

claunia commented

@tebeco commented on GitHub (Jun 28, 2020):

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

@tebeco commented on GitHub (Jun 28, 2020): > 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

claunia commented

@sanket-bhalerao commented on GitHub (Jul 8, 2020):

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

@sanket-bhalerao commented on GitHub (Jul 8, 2020): 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 ![image](https://user-images.githubusercontent.com/9264813/86882513-ffe2a300-c10d-11ea-81b3-d6e0058b3632.png)

claunia commented

@JongleurNin commented on GitHub (Jul 9, 2020):

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 commented on GitHub (Jul 9, 2020): 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.

claunia commented

@tebeco commented on GitHub (Jul 9, 2020):

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

@tebeco commented on GitHub (Jul 9, 2020): @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](https://docs.github.com/en/rest/reference/repos#list-release-assets) here you want this https://api.github.com/repos/microsoft/terminal/releases/latest * you could use `pwsh` [`ConvertFrom-Json`](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertfrom-json?view=powershell-7) * 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 ;)

claunia commented

@MrM40 commented on GitHub (Jul 25, 2020):

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

@MrM40 commented on GitHub (Jul 25, 2020): > * 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!)

claunia commented

@carwyn commented on GitHub (Jul 25, 2020):

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

@carwyn commented on GitHub (Jul 25, 2020): > @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!?

claunia commented

@tebeco commented on GitHub (Jul 25, 2020):

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

@tebeco commented on GitHub (Jul 25, 2020): 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

claunia commented

@carwyn commented on GitHub (Jul 25, 2020):

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?

@carwyn commented on GitHub (Jul 25, 2020): > 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?

claunia commented

@tebeco commented on GitHub (Jul 25, 2020):

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 commented on GitHub (Jul 25, 2020): 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

claunia commented

@tebeco commented on GitHub (Jul 25, 2020):

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

@tebeco commented on GitHub (Jul 25, 2020): 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` ```pwsh [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 ```

claunia commented

@0x7FFFFFFFFFFFFFFF commented on GitHub (Aug 23, 2020):

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.

@0x7FFFFFFFFFFFFFFF commented on GitHub (Aug 23, 2020): > > > 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` > > > ```powershell > [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.

claunia commented

@tebeco commented on GitHub (Aug 23, 2020):

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 commented on GitHub (Aug 23, 2020): 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

claunia commented

@DHowett commented on GitHub (Aug 23, 2020):

@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

@DHowett commented on GitHub (Aug 23, 2020): @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 ```

claunia commented

@tebeco commented on GitHub (Aug 23, 2020):

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

@tebeco commented on GitHub (Aug 23, 2020): 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

claunia commented

@DHowett commented on GitHub (Aug 23, 2020):

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

@DHowett commented on GitHub (Aug 23, 2020): 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:

claunia commented

@tebeco commented on GitHub (Aug 25, 2020):

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

@tebeco commented on GitHub (Aug 25, 2020): 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

claunia commented

@johan-boule commented on GitHub (Dec 9, 2020):

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.

@johan-boule commented on GitHub (Dec 9, 2020): 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.

claunia commented

@tebeco commented on GitHub (Dec 9, 2020):

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 : https://github.com/microsoft/terminal/issues/1386#issuecomment-663856089
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

@tebeco commented on GitHub (Dec 9, 2020): 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 : https://github.com/microsoft/terminal/issues/1386#issuecomment-663856089 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

claunia commented