terminal 🚀 - 研究 Windows 终端的替代部署机制

让我知道是否/何时有人在看这个。我们正在为 WinDbg Preview 走这条路，因此我们可能会对我们查看的选项和优缺点有一些指导。

aluhrs13 于 2019-06-22

这是一个令人兴奋的功能。

jliuold 于 2019-06-22

👎2

安装 Visual C++ Redistributable
https://aka.ms/vs/16/release/vc_redist.x64.exe
访问https://dev.azure.com/ms/Terminal/_build
选择最近的master构建
点击工件
点击 appx-发布
提取appx-Release.zip
提取CascadiaPackage_0.0.1.0_x64.msix
打开WindowsTerminal.exe

请注意，这实际上对我不起作用，终端没有打开。
然而，也许有人可以从这里找到丢失的部分。

ghost 于 2019-06-22

👍5 😕1

您缺少的是vcruntime140_app和msvcp???_app应用程序容器运行时的本地副本。否则，Windows 终端应该可以双击激活。

DHowett-MSFT 于 2019-06-22

究竟为什么 MS 发布了一个不能在服务器上使用的终端应用程序呢？

你真的认为你的主要用户只使用 Windows 10 吗？

我知道你们正在尝试拥抱开发和开源世界，但可能会在发布在不太可能成为主要用户的环境中的出色工具之前询问您的用户他们想要什么。

我正在看这个帖子，希望有人知道如何做到这一点；我可以编译它，但不幸的是在工作中安装 C++ 构建堆栈不会发生。

methodbox 于 2019-06-22

👎34 👍30 👀2

@methodbox你不需要对它不友好☹️。我们听到你响亮而清晰的声音。我们知道我们需要几个不同的分发模型。

DHowett-MSFT 于 2019-06-22

👍39 ❤9 👎2 👀1 😕1

再说一次，我听到了。这是交易：_这是一个预览版本_，鉴于我们可用的资源，我们必须确保我们明智地投资它们。让其他人进行分发和安装可以节省整整一个月的工程时间，否则将花费在我们所有支持的配置上构建和测试安装程序。这就是为什么它在我们的_backlog_上。我们认识到这对我们的大部分潜在用户来说极为重要，但我们首先会优先考虑功能和性能以及错误修复。

DHowett-MSFT 于 2019-06-22

👍28 👎2 👀1

再说一次，我听到了。这是交易：_这是一个预览版本_，鉴于我们可用的资源，我们必须确保我们明智地投资它们。让其他人进行分发和安装可以节省整整一个月的工程时间，否则将花费在我们所有支持的配置上构建和测试安装程序。这就是为什么它在我们的_backlog_上。我们认识到这对我们的大部分潜在用户来说极为重要，但我们首先会优先考虑功能和性能以及错误修复。

我想我对此感到困惑。你说让别人分发它会节省时间和精力，（别人是 GitHub？）但这不是首先做的吗？

我也不是不友善。我问了一个严肃的问题，并发表了一些严肃的声明。

我没有时间在工作中安装所有 VS 必需品来编译它并尝试在 Windows Server 上使用它，或者我会，而且我也不了解 Windows 10 的目标受众，我有理由好奇是否有什么东西我不知道这会使他们成为第一个目标。

很抱歉，批评似乎不友好，但这些都是合理的担忧。

methodbox 于 2019-06-22

👎23 👍16 😕4

需要一个可复制的 exe。控制台等电动工具不需要安装程序。安装程序是一种矫枉过正，请避免它。因此，您无需花费数月的时间进行测试。上次我检查时，Visual Studio 有能力在正式签名的发布模式下生成 exe。
作为高级用户，我们对选择商店作为主要分销模式的决定印象不深。因为，昨天我试图在我的工作机器上安装这个控制台并猜猜是什么，商店配置了我的 Hotmail 帐户，因为它需要一个不是我的工作帐户的 Microsoft 帐户，我可以选择在我的个人 PC 上安装控制台在家里。我需要在我的工作机器上而不是在我的个人机器上使用控制台。
总而言之，只是简单而已。使获取此工具变得容易，以便我们可以使用它。否则，我对使用多年的 ConEmu 感到满意。

amithegde 于 2019-06-22

👍23 👀1

便携版是我们越来越严格的企业开发环境的必备品。
我们在我们的桌面上没有管理员权限，希望我们有 zip 版本的 vscode、pwsh、python、git、conemu 等，所以我真的很想在终端上看到同样的东西。

copdips 于 2019-06-23

👍14

安装 Visual C++ Redistributable
https://aka.ms/vs/16/release/vc_redist.x64.exe
访问https://dev.azure.com/ms/Terminal/_build
选择最近的master构建
点击工件
点击 appx-发布
提取appx-Release.zip
提取CascadiaPackage_0.0.1.0_x64.msix
打开WindowsTerminal.exe
请注意，这实际上对我不起作用，终端没有打开。
然而，也许有人可以从这里找到丢失的部分。

您应该使用 PowerShell 注册应用程序，而不是运行 WindowsTerminal.exe：
Add-AppxPackage .\AppxManifest.xml -Register

然后它会显示在“开始”菜单中，您可以从那里启动它。
请注意，您可能需要先在设置菜单中启用开发人员模式，我已经启用了它，所以我不确定没有它是否可以工作。

HackershubNL 于 2019-06-24

👍4 😕1

感谢您满足开发者社区对更好终端的需求。这是我多年来一直想在 Windows 上看到的应用程序，并希望能尽快推出。我很高兴从 master 那里获得一个版本，但我目前使用的是 Windows Server 2019 Datacenter LTSC。

问：

支持 Windows Server 2019 LTSC、Microsoft Windows NT 10.0.17763.0
README.md 中的安装说明或此类说明的链接：

安装 Visual C++ Redistributable（参见 https://aka.ms/vs/16/release/vc_redist.x64.exe）
访问https://dev.azure.com/ms/Terminal/_build
选择最新的主版本
点击工件
点击 appx-发布
提取 appx-Release.zip
提取 CascadiaPackage_0.0.1.0_x64.msix
打开 WindowsTerminal.exe

David-Noble-at-work 于 2019-06-25

👍5 😕4 👎3 ❤2

您缺少的是vcruntime140_app和msvcp???_app应用程序容器运行时的本地副本。否则，Windows 终端应该可以双击激活。

@DHowett-MSFT 你能给我们一些关于如何安装它们的指导吗？

我很想在工作中测试它，但没有机会在那里使用 Windows Store。我尝试在早期版本上自己构建它，甚至设法做到了，但由于构建后 Visual Studio 要求和 repo 本身之间花费了近 40GB，因此在我有限的 SSD 空间上很快变得无法管理。

顺便说一句，不要介意负面评论。终端运行良好（真的，我用 WSL 2 测试了它，而且我以前从未在 Windows 上获得过如此流畅的终端体验）。有些人不明白预览的意义，但那是因为他们也很期待它。

随着时间的推移，它将不再预览，每个人（或至少大多数用户）都会很高兴。

thomazmoura 于 2019-06-25

2. 访问https://dev.azure.com/ms/Terminal/_build

非 MSFT 人员无权访问这些工件

pkzOR 于 2019-06-27

👍6 😄5 👎3

我下载了工件，但无法通过双击安装 .msix，因为它说它没有由受信任的证书签名。

我已经设法通过下载工件、将 .msix 解压缩到一个文件夹然后从文件夹内的 Powershell 运行Add-AppxPackage AppxManifest.xml -Register来让它工作。现在我可以通过从开始菜单打开“Windows Terminal (Dev Build)”来运行它。

一个相当hacky的过程，但它现在有效。

thomazmoura 于 2019-06-27

👍1

Windows 商店是一个损坏的软件。这就像一个爱发牢骚的婴儿，总是需要你的关注，从不做任何你期望它做的事情。依靠它就像说_请不要安装我们的东西_一样好。

我刚从#1757 被重定向到这里，很高兴看到这方面的吸引力。

为什么要把一件简单的事情复杂化？下载，安装，应该就是这样。

mrchief 于 2019-07-01

👎3 👍2

这是交易：这是一个预览版本

是的，人们已经对此感到兴奋。处理命令行记事本（又名 cmd.exe）的痛苦一定会让人抓狂，以促使人们尝试更好的终端，即使它是预发布的。另外还有推特炒作。

请不要将我们的评论视为咆哮。我们_想要_尽快得到它。把我们送到商店是在关上我们的门。我们也想明智地投资我们的时间。花费他们修复 Windows 商店问题绝对不是对任何人时间的有效利用。希望你能理解！

mrchief 于 2019-07-01

👍6

我对这种“安装”体验感到非常沮丧。我将 install 放在引号中，因为我实际上无法安装它。商店给了我一个我的一些机器的列表，以进行安装......但不是我实际使用的机器。即使我选择列出的机器之一，它也会告诉我它正在尝试安装，但显然没有安装任何东西。我可以将零反馈用作故障排除的起点——没有错误消息或日志信息，只是沉默。

我很烦恼不只是一个普通的安装程序，就像我们几十年来一直在使用的那样。而且我很困扰 Windows Store 似乎无法定位我实际使用的机器（这不应该是给定的吗？？）。恕我直言，我不想花时间对我的 Windows 应用商店环境进行故障排除来弄清楚它为什么不承认我的系统（是的......它绝对符合要求）或者为什么安装过程似乎绝对什么都不做。我不经常使用商店，但我不记得曾经为安装选择目标系统。这是一个新功能吗？无论哪种方式，这种经历都是可怕的。

我已经做了 20 多年的开发人员。但即使我不想为此下载源代码并进行编译。我只想要一个可以安装和运行的编译可执行文件。

drullo 于 2019-07-02

👎2

@drullo检查您的操作系统信息。这不是很明显，但如果你向下滚动一点，它会显示你当前与所需的配置。如果是这种情况，那么您必须决定是否要冒险升级到当前的操作系统版本或不使用终端。

这些在理论上都不是坏事，但是它（Windows 商店）的实现方式非常丑陋（不稳定，很多事情都可能而且将会出错），老实说，不值得花时间去安装一个应用程序（不仅仅是终端但任何商店应用程序）。

可悲的是，Mac 上的 App Store 和 OS 更新是一种更加流畅的体验。它有它自己的问题，但没有一个处于原始的、基本的水平。

mrchief 于 2019-07-02

请提高此功能的优先级...这可能是被问到最多的功能...

VimalShekar 于 2019-07-09

👎2 👍2

作为替代分发的第一步，我已将（已签名、可存储更新的）MSIX 捆绑包发布到发布页面。它们应该可以在 1903+ 上双击安装，但可能需要安装一些依赖包。我们正在努力使这个过程变得更好一点。请多多包涵。

现在，我们_需要_一个 MSIX/appx 安装上下文，用于资源查找（图标、字符串等）和组件激活（以便我们可以加载我们的组成 DLL），但正在使该要求更加宽松一些方面取得进展，因为好吧。

DHowett-MSFT 于 2019-07-10

👍7 🎉1

我实际上喜欢使用 msix 部署的想法。 Msix 甚至支持 Windows 7，因此使用 msix 双击安装会很棒。

WSLUser 于 2019-07-12

@DHowett-MSFT 这是一个好的开始！

将来我仍然想要便携式版本（例如 sysinternals 应用程序）
请更新提供发布页面链接的自述文件，以便人们可以真正注意到它在商店之外可用。

amithegde 于 2019-07-13

@amithegde我们已更新自述文件 - 感谢您的建议。

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

bitcrazed 于 2019-07-30

👍3

尝试使用 MSIX 从发布页面脱机安装，并在启动 WindowsTerminal.exe CLiP 设备许可证时收到错误消息未找到。不知道如何解决这个问题

rismoney 于 2019-08-02

离线安装程序迫切需要在我们的服务器上安装 WT。

gh4chris 于 2019-08-05

在几次尝试安装 Windows 终端失败后，我发现了这个问题。这里的问题是，在许多专业环境中使用的 Windows 10 LTSC（长期支持版本）是版本 1809（内部版本 17763），而 Windows Terminal 被打包为 MSIX 档案的 MSIX 包，只能安装在更新版本的 Windows 10 上。

这使得 Windows Terminal 在当前状态下无法在专业环境中使用。虽然正如微软所说，下一个 LTSC 将在 2021 年之前发布。如果不提供另一种部署机制，Windows Terminal 将在两年内无法在专业环境中使用。

我不是以 Windows 为中心的开发人员，所以我不知道将静态链接的 exe 文件作为一种快速而肮脏的临时解决方案发布的成本/负担是什么，但如果可能的话，那就太好了。事实上，任何形式的独立/便携版本都将不胜感激（正如所有先前的评论所强调的那样；））。

编辑：

一些额外的想法，

在专业环境中，Windows 应用商店通常被禁用（因此在我看来，激活开发人员模式并使用add-appxpackage可能需要在 README 中提供明确的文档）；
最好在自述文件中澄清兼容性要求（就需要/兼容的 Windows 10 版本而言）。

NBardelot 于 2019-08-06

👍7

@NBardelot在“专业环境”中，您不可能同时需要 LTSC 版本的 Windows 和 Windows 终端，嗯，除非您运行我怀疑的非常关键的系统，否则您不需要 LTSC。
在“专业环境”中，如果您需要拥有可从 Microsoft Store 获得的应用程序，则可以通过标准流程来请求通常存在于您公司 (ITIL) 中的东西。
Windows Terminal 的目标是拥有 Windows Insider 版本的开发人员——我不理解在 LTSC 中拥有它的论点，尤其是当它在与 LTSC 目的相矛盾的PREVIEW中时。
运行它必须具备的条件非常清楚： Requirements & 和 Microsoft Store。

@gh4chris并不急需，CMD 和 PowerShell 在 Windows Server 中可用 - 没有合理的论据为什么需要它。

CatTheHacker 于 2019-08-06

👎3 👍1

对于任何企业采用，都应该假设非商店使用是必需的。大多数构建良好的生产环境都无法访问互联网并使用部署工具。

为什么在便利性方面甚至存在阻力？

rismoney 于 2019-08-06

👍4

因此，作为记录，我们确实提供了非商店安装机制 - 请参阅我们的发布页面。但是，我们并不能在 Windows 构建版本要求上做出让步。我们依赖于一些仅在最新版本的 Windows 10 中提供的操作系统功能。这就是我们无法在 LTSC 上工作的真正原因。

zadjii-msft 于 2019-08-06

👍1

@zadjii-msft 这是完全可以理解的，但我必须再次强调，遗憾的是，对于许多有趣的用例（以及广泛采用，一旦你将处于发布模式），这意味着直到 2021 年才会有 Windows 终端。如果有任何方法可以解决您所说的这些限制，我希望您将其考虑在内:)

@CatTheHacker感谢您的见解。还请理解，告诉其他人你最了解他们需要什么是不礼貌的，因为你没有所有可用的信息并且可能会误解限制。也就是说，我很乐意说明我的用例，因为您的误解也是我缺乏解释。

我目前在一家大公司的一个非常安全的环境中工作。出于安全性和可维护性的原因，台式机运行 Windows 10 LTSC（我无权更改）。我说的不是关键机器/服务器，而是开发和运营工作站。我们的目标之一是对 ITIL / 存储库等中尚未简化的工具进行原型设计和测试，并探索可以做些什么来使开发和运维的生活更轻松。这甚至让我们将操作系统与操作系统工具进行比较，这对于这类公司来说是一个真正的范式转变。在这种情况下，需要运行 Windows Terminal 的预览版，并开始向人们展示如何与终端（因为 Powershell、docker、kubernetes/openshift...）很好地协作。

NBardelot 于 2019-08-09

👍5

如果有一种方法可以从命令行自动安装 Windows 终端应用程序，那就太好了。

TechWatching 于 2019-08-19

@NBardelot - 感谢您在这里提供信息和想法。

MSIX

目前，我们正在将 Terminal 构建到 MSIX 包中，因为这是在 Windows 上打包应用程序的战略路径。如果有足够的需求，我们不反对考虑其他封装格式，但目前我们专注于主流场景来满足社区的大部分需求。

也就是说，我正在深入研究 MSIX 团队的计划。 LTS SKU。当我收到他们的回复时会通知你。

LTS

请注意，LTS SKU 的定义比一般发行版 SKU 更受限制且更新频率更低。因此，新产品和功能很可能需要更长时间才能到达和/或不受 LTS SKU 支持。简而言之，如果您想在最新最好的工具和技术发布后立即运行它们，您可能需要考虑非 LTS SKU。

需要更好地控制其平台配置，同时还允许用户自行部署批准的应用程序和/或部署已知托管应用程序的企业可能希望探索可与 SCCM 和 InTune 集成以实现自动部署等的 Windows Store For Business . 批准的应用程序。

我们将很快更新我们的文档 v. 并且肯定会纳入您的一些反馈和要求，以使该领域更易于理解。

bitcrazed 于 2019-08-21

仅供参考，现在有一个巧克力包，所以可以运行choco install microsoft-windows-terminal来安装应用程序。

非常感谢@mkevenaar ，他似乎把这些放在一起！ 🎉

SeanKilleen 于 2019-09-01

🎉5 👍2 ❤1 😕1

@SeanKilleen绝对 - 我是 Chocolatey 的超级粉丝，并感谢@mkevenaar创建 Chocolatey 包以引用我们的最新版本 :)

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

bitcrazed 于 2019-09-05

👍4 😕1

@SeanKilleen绝对 - 我是 Chocolatey 的超级粉丝，并感谢@mkevenaar创建 Chocolatey 包以引用我们的最新版本 :)
https://github.com/mkevenaar/chocolatey-packages/blob/master/automatic/microsoft-windows-terminal/update.ps1#L8

@bitcrazed不客气！它每 6 小时运行一次更新脚本，通常只需不到 1 小时即可被巧克力网站处理！

mkevenaar 于 2019-09-05

👍2

[更新：替换了之前的链接]：

如果您手动安装 Windows 终端，并且没有安装 VC Redist，终端将无法安装和/或运行。

请下载并安装 Desktop Bridge 的 C++ Runtime v14 框架包：
https://www.microsoft.com/en-us/download/details.aspx?id=53175

C++ 运行时框架包将被复制到 %ProgramFiles(x86)%\Microsoft SDKs\Windows Kits10\ExtensionSDKs\Microsoft.VCLibs.Desktop 下的文件夹中。

👉 注意：您也可以使用 Add-AppxPackage PowerShell cmdlet 手动安装包。

（与#2369 相关）

bitcrazed 于 2019-09-27

^ 它对我来说仍然失败。它尝试从商店安装Visual C++ run-time for UWP ，不幸的是，由于限制，商店无法访问互联网。

从 choco 安装后的事件出现此消息：
Capture

mubaidr 于 2019-10-03

嘿@mubaidr ：我已经更新了上面的回复以链接到桌面桥VC++ Runtime redist。请尝试一下，如果它解决了您的问题，请告诉我。

bitcrazed 于 2019-10-08

👍1

仍然是相同的错误消息:(
Capture

mubaidr 于 2019-10-09

我们的系统管理员禁用了 Windows 应用商店，并且我们没有开放的互联网连接。所以我们需要一个安装包。

rfresow 于 2019-10-10

👍3

@rfresow - 我们将每个公开发布的终端版本发布到商店和此 repo 中的版本： https ://github.com/microsoft/terminal/releases

⚠ 注意：由于您是手动安装，请务必定期手动更新 - 我们的目标是每月发布一次。

bitcrazed 于 2019-10-11

👍1

@mubaidr - 抱歉，您在这里遇到了问题。我可以要求您卸载终端，重新启动机器，重新安装吗？我担心您的机器配置出现异常情况。

bitcrazed 于 2019-10-11

^ @bitcrazed我也开始这么想了。规划新的设置。卸载和重新启动也没有帮助。所以我将从一个干净的设置开始。

mubaidr 于 2019-10-11

FWIW，我一直在遇到相同的 VC 要求。由于各种原因（离线网络等），我们也可以访问 Windows 应用商店

如果可以根据需要在跳转主机等设备上安装终端，那就太好了。

miketheitguy 于 2019-10-13

嘿@mubaidr ：我已经更新了上面的回复以链接到桌面桥VC++ Runtime redist。请尝试一下，如果它解决了您的问题，请告诉我。

@bitcrazed我相信上面的下载对于终端的构建来说还不够新。我的抱怨版本...

从您的链接安装 UWP VCLib 后，它的版本为 14.24222.0（来自 Programs & Features）；但如果我做 Get-AppXPackage：

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

上面的链接是2016年的...

miketheitguy 于 2019-10-13

同样的问题 -链接中的vc_uwpdesktop.140.exe文件包含旧版本的 Microsoft.VCLibs - 在C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\Appx\中安装它之后，您可以找到：

“零售”文件夹中的 14.0.24217.0 版本
“调试”文件夹中的 14.0.24222.0 版本

Windows 终端需要最低版本14.0.27323.0 。有什么方法可以在不启用商店的情况下安装它？

RafneQ 于 2019-10-23

👍3

几个月前，我使用 VS2019 和 W10 1903 从源代码构建（并且一直在使用）终端。但是，我似乎无法执行新的msixbundle ，我没有权限访问 Azure 工件，当我执行git pull并尝试在 VS 中重建时，即使在获取推荐的 NuGet 更新并安装 Dot Net 4.7.2 之后，我也遇到了大量错误。

悲伤:(

mikepurvis 于 2019-11-07

无论如何都不支持 Windows Server 2019。是的，我们只使用 LTSB 版本不是因为我们是“反动派”。但是因为我们在拥有超过 5000 台服务器的真实企业中工作，甚至尝试每年更新它都是一个血腥的地狱。

ertyz 于 2019-11-11

❤1

将所有这些其他项目链接到这个 bug 非常棒 - 但对于许多希望在服务器操作系统上安装它的人来说，这是在浪费时间。请在项目自述文件中添加一行内容：

“希望在 Windows Server 2019 上安装 Windows 终端？-我们还没有，稍后再回来！...”

VimalShekar 于 2019-11-15

👍9

将所有这些其他项目链接到这个 bug 非常棒 - 但对于许多希望在服务器操作系统上安装它的人来说，这是在浪费时间。请在项目自述文件中添加一行内容：
“希望在 Windows Server 2019 上安装 Windows 终端？-我们还没有，稍后再回来！...”

自述文件已经指出：

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

amithegde 于 2019-11-19

👍2 👎1

同样的问题 -链接中的vc_uwpdesktop.140.exe文件包含旧版本的 Microsoft.VCLibs - 在C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\Appx\中安装它之后，您可以找到：
“零售”文件夹中的 14.0.24217.0 版本
“调试”文件夹中的 14.0.24222.0 版本
Windows 终端需要最低版本14.0.27323.0 。有什么方法可以在不启用商店的情况下安装它？

我在没有 Microsoft Store 访问权限的环境中也遇到了这个问题。看来我安装的版本是14.0.26905.0。您通过手动下载获得的版本是 14.0.24217.0。如果没有 MS Store，我看不到任何安装 14.0.27323.0 的方法。

oryandunn 于 2019-11-21

“零售”文件夹中的 14.0.24217.0 版本
“调试”文件夹中的 14.0.24222.0 版本

我已经安装了这些版本，并且终端 0.6.2951.0 运行正常。

也许 VC 14.0.27323.0 安装在我系统的其他地方，但我想没有。哪里提到了这个要求？

DavidA2014 于 2019-11-22

“零售”文件夹中的 14.0.24217.0 版本
“调试”文件夹中的 14.0.24222.0 版本
我已经安装了这些版本，并且终端 0.6.2951.0 运行正常。
也许 VC 14.0.27323.0 安装在我系统的其他地方，但我想没有。哪里提到了这个要求？

您的计算机是否可以访问 MS Store？我的没有。我最近升级到 1909，这可能是我的版本 14.0.26905.0 的来源，但我不确定。

这是我尝试安装时遇到的错误：

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 于 2019-11-22

“零售”文件夹中的 14.0.24217.0 版本
“调试”文件夹中的 14.0.24222.0 版本
我已经安装了这些版本，并且终端 0.6.2951.0 运行正常。
也许 VC 14.0.27323.0 安装在我系统的其他地方，但我想没有。哪里提到了这个要求？

您的计算机是否可以访问 MS Store？我的没有。我最近升级到 1909，这可能是我的版本 14.0.26905.0 的来源，但我不确定。

这是我尝试安装时遇到的错误：

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

我最近将同一环境中的另一台 PC 升级到 1909。我能够安装最新的 Windows Terminal 0.6.2951.0。原来，这台机器有 UWPDesktop v 14.0.27810.0。虽然我认为这可能是因为这台机器安装了 VS2017 和 VS2019，但我不能 100% 确定它是在何处、何时或如何安装的。

似乎需要做的是下载这个
https://www.microsoft.com/en-us/download/details.aspx?id=53175
更新为版本 14.0.27810.0（或更高版本）。我不确定为什么自 2016 年以来下载量一直停滞不前。

oryandunn 于 2019-11-25

👍2

更新：我们正在内部进行一些对话以解决此问题。敬请关注。

bitcrazed 于 2019-11-25

👍11 🎉1

FWIW，我在永远不会连接互联网的环境中工作。 Azure、M365 等获得的认证该死。他们永远不会有互联网连接。

miketheitguy 于 2019-11-26

👍1

Windows 终端已在Scoop中可用。 Scoop 使用 7zip 从 msix 中提取文件，效果很好。所以我猜 Windows 终端已经是可移植的了？似乎并非所有 msix 安装程序都可以这样工作。

linsui 于 2020-01-09

如今，终端确实可以在未打包的情况下工作，但我们目前不能保证它总是会这样。

DHowett-MSFT 于 2020-01-09

👍1

在 Windows Server 2019 上使用巧克力失败：

choco install microsoft-windows-terminal
错误：此软件包至少需要 Windows 10 版本 1903/OS build 18362.x。
microsoft-windows-terminal 的安装不成功。

是否有不同版本的 windows server 或者它们都太旧了？

ArgTang 于 2020-01-13

@ArgTang我相信没有任何服务器版本可用： https ://github.com/microsoft/terminal/issues/2312#issuecomment -519318609

mkevenaar 于 2020-01-13

👍1

确实！ /重复＃2312。

DHowett-MSFT 于 2020-01-13

你好！我们已将此问题识别为与此问题跟踪器上已存在的另一个问题的重复。正在关闭此特定实例，以便跟踪对引用线程的关注。感谢您的报告！

msftbot[bot] 于 2020-01-13

目前，Server 在 1903 或 1909 版本中不可用。对于那个很抱歉！

DHowett-MSFT 于 2020-01-13

我绝对不是要关闭这个主跟踪错误。对不起大家！

DHowett-MSFT 于 2020-01-13

到目前为止，我发现在工作中也绝对没有解决方法
由于上一期已关闭，我在这里更新最新发布的版本：
（在此处复制粘贴上一期，以免从 #4424 丢失轨道，对不起@DHowett ，我认为这有助于查看每个已发布版本的行为是否不时更改）

结果在这里： https ://github.com/microsoft/terminal/issues/4424 问题已关闭，有利于这个问题

我唯一有效的版本是我手动构建的0.6xxxx ，当我尝试在19041 slow ring或1909 stable上构建0.8.x时，我遇到mdmerge.exe崩溃1909 stable

从已关闭的问题中复制粘贴：

最后一个WindowsTerminal_0.8.10261.0_x64__8wekyb3d8bbwe msixbundle确实安装但应用程序崩溃，如果我从chocolatey安装也是如此

@DHowett

感谢msixbundle的改进，因为它没有安装，并开始运行。
你能告诉我如何获得有关为什么它在运行时崩溃的信息，以便我可以创建一个适当的问题，以便在以后的版本中解决它吗？

我可以看到边框出现了半秒钟，然后崩溃了：

如果我打开速度足够快Start Menu我可以看到可能有某种MS Store Post Action （进度条）：

我怎么能帮忙？
我想知道日志在哪里诊断。
我不确定在EventViewer中的何处查看（我试图检查但没有发现任何看起来像崩溃的东西）

[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 于 2020-02-07

如果当前的安装状态有任何帮助，请告诉我。

我还没有找到一种方法来获取未找到的日志/诊断/跟踪，因此它可以帮助提供有关此特定行为的反馈，以查看是否以及如何修复它^^

我不介意没有“商店更新”，因为......公司锁定了商店。
这就是为什么现在我尝试至少使用一次msixbundle ;)
当我需要更新时，我会重新安装下一个msixbundle

tebeco 于 2020-02-07

感谢大家对此事的耐心等待。

我们完全理解这里发生了什么，但不想提供一个 hacky 解决方案。

我们正在内部积极与多个团队合作，为这个问题提供一个长期可支持的解决方案，一旦我们知道什么时候可以做什么，我们会在这里报告。事实上，大约 20 分钟前，我提出了一个正式的请求，要求另一个团队为我们做一些工作。

敬请关注。

bitcrazed 于 2020-02-08

👍15

抱歉@iamdeskoh - 删除此评论，因为它建议从未经验证、不受信任的来源下载软件包。绝对不推荐这种做法。我们不希望有人因为这样做而无意中感染了令人讨厌的东西。

请放心，我们会在内部进行调查以解决此问题。请耐心等待我们。

@bitcrazed

deskoh 于 2020-02-26

😕1 👎1 👍1

不，不会点击那个链接

为什么我会尝试单击未知/不受信任的域？
特别是从非官方来源安装二进制文件

在发送链接并要求用户单击它之前，您可能首先要解释网站的目的是什么。我也想它在网站背后所做的是开源的，所以它可以被信任^^？

我并不是说它不起作用，只是你无法相信第三方运送魔法二进制文件
尤其是当你可以先在这里询问windows/terminal团队是否能够解决这个问题时

tebeco 于 2020-02-26

👍2

我也不太喜欢这种解决方法，但下载链接来自 Microsoft 域。 @deskoh提供的网站似乎只是提供了指向 Microsoft Store 中未列出内容的链接。
如果团队可以提供一种方法来为他们的项目安装所需的依赖项，那么人们就不必用这样的解决方法来试试运气了......
但即使在安装了最新版本的 Microsoft.VCLibs.140.00.UWPDesktop 之后，由于另一个错误，安装仍然失败。

clement-fischer 于 2020-02-26

@clement-fischer 你遇到了什么错误？我终于设法在气隙环境中运行它。您将需要 VC++ 可再发行组件。我还必须从 WindowsApp 目录启动终端。

deskoh 于 2020-02-26

@deskoh虽然我尝试通过 Powershell 安装，但错误似乎与 #3194 中的相同。

clement-fischer 于 2020-02-27

我尝试了几种手动安装 msix 和 appx 的方法，并且 Windows 终端版本似乎被锁定到比最新的 Windows Server 2019 版本更新的 Windows 10 版本。

这是相当不幸的。

XenHat 于 2020-04-03

遗憾的是，对于我们所有人来说，这个功能不会在 Terminal 1.0 版本中提供。因此，终端对于实际生产环境中的 IT 专业人员来说仍然毫无用处： https ://github.com/microsoft/terminal/milestone/6

ertyz 于 2020-04-23

👍1

如果他们修复了依赖项的可用性，那么应该可以手动安装。问题 #3097 被列为 1.0 的必需问题之一。

oryandunn 于 2020-04-24

我不能告诉其他用户，但我非常喜欢让msixbundle在任何地方工作，即使这意味着我以后必须自己更新它。
这就是我在第一次预览后在工作中使用Powershell Core 7.x的方式。

最重要的是，有一条很好的消息通知你在 shell 内部（所以不是侵入性的）你错过了一个更新。
我认为还有一个选择退出

例如，手动提取msixbundle会更好

tebeco 于 2020-04-24

与勺子配合得很好，我们可以在专业环境中使用它。（来自我们的专业 Windows 桌面）：
https://github.com/lukesampson/scoop-extras/blob/master/bucket/windows-terminal.json
scoop install windows-terminal

copdips 于 2020-04-24

谢谢你！

独家新闻是有史以来最酷的东西！
https://youtu.be/a85QLUJ0Wbs

这是一个很好用的工具，有家的感觉

Am Fr., 24. Apr. 2020 um 12:03 Uhr schrieb Xiang ZHU <
通知@github.com>：

gh4chris 于 2020-04-24

好吧，仍然不能用于 Windows Server 环境：

iwr -useb get.scoop.sh | 即
Set-ExecutionPolicy RemoteSigned -scope CurrentUser
舀安装 git
铲斗添加斗额外
舀安装Windows终端
安装 'windows-terminal' (0.11.1121.0) [64bit]
Microsoft.WindowsTerminal_0.11.1121.0_8wekyb3d8bbwe.msixbundle (16,1 MB)[======================================] 100%
检查哈希Microsoft.WindowsTerminal_0.11.1121.0_8wekyb3d8bbwe.msixbundle ...好的。
提取dl.7z ...完成。
正在运行预安装脚本...
正在运行安装程序脚本...
*错误至少需要 Windows 10 18362。 *

gh4chris 于 2020-04-24

@gh4chris
在桌面上也一样吗？
由于终端依赖于操作系统的特定功能，因此需要一定的最低版本级别

您可能想更新到 1903 / 1909（2004/20H1 应该在不到一个月的时间内登陆）

tebeco 于 2020-04-24

你看？这在专业环境中是有问题的。更新涉及
大量验证不会破坏现有设置...

我怀疑 WT 真的需要这样的依赖。 IT 使整个项目
或多或少可笑

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

gh4chris 于 2020-04-24

我了解您在更新公司中的服务器时遇到问题，这是与部署无关的不同问题。
您可能需要联系您身边的团队以更新他们的形象，以至少获得一年前的形象。

这与“商店还没有其他选择”有点不同

我不会说它是阻塞的或有问题的。例如，您可以使用Enter-PSSession或ssh ，然后在使用服务器的 $#$3$# WT时，您将使用计算机中的Shell
如果愿意，您甚至可以在服务器上更新为PSWS 7.x ，或者将其安装为dotnet tool

您可能想打开Investigate alternative deployment mechanisms for Windows Terminal以外的另一个问题

tebeco 于 2020-04-24

我真的不想卷入这里正在酝酿的关于什么是“真实环境”的争论

但我当然希望它在 Windows Server（任何版本）上运行，并且在我的情况下让它在 Windows 10 上运行也没有用。

bjtucker 于 2020-05-01

👍2

我只想说更新到 Windows Server 2019
但这可能是一个难以接受的药丸，因为即使 Azure 门户网站也没有为其提供模板
（但是，是的，我想“只是更新”）

另外，由于我只是像您这样的消费者，您可以为此提出一个问题，因为它与此无关吗？
也许在那里问为什么以及有关最低操作系统版本的详细信息
但与部署机制无关

tebeco 于 2020-05-01

嘿@DHowett ，您将deps 捆绑到终端的提交（我知道尚未发布）应该对离线msixbundle 安装程序有很大帮助。

似乎在那之后，一个健全的离线安装方法的主要缺失部分是有一个 aka.ms 静态 URL 来下载最新的 msixbundle，而不是让你的脚本与最新的 github.com 版本保持同步和下载网址。

是否可以获得此捆绑包的静态下载链接？

holtwilkins 于 2020-05-04

是否可以获得此捆绑包的静态下载链接？

这不是一个坏主意，这可能是我们需要尽早而不是以后做的事情。

我更愿意提供一个appinstaller （这几乎是一个带有“我在哪里可以找到更多你的人？”标签的 msixbundle（用于更新！）），但这实际上需要这个，所以_shrug_。

DHowett-MSFT 于 2020-05-05

*错误至少需要 Windows 10 18362。 *

为什么会有这么奇怪的硬性要求？不能降低对它的依赖，以便它可以在 LTSC 版本上使用吗？

Kein 于 2020-05-26

👀1

@kein这是我们之前在这个 repo 上详细讨论过的内容。

第1643章（评论）
对不起。目前，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.
我们只是无法回到 1809 年。
第1909章（评论）
Windows 终端需要来自最新 Windows 版本的功能。
不幸的是，我们确实没有可用的解决方法。 XAML Islands 是我们用来在 Win32 进程中托管 XAML UI 的技术。没有它，我们将无法显示任何内容。由于 XAML 岛仅在最新的 Windows 10 版本中完成，因此我们无能为力。
如果您想使用终端，您将_需要_使用最新的 Windows 10 版本。
第841章（评论）
第498章（评论）
目前没有计划。
我们的 UI 依赖于 C++/WinRT 和 XAML 岛 (UWP XAML)。我们还将 DX/DWrite 用于文本渲染器。除非它们在某个时候被移植到 linux，否则我会说我们支持 linux 的可能性很小。
此外，我们的整个构建系统都是基于 MsBuild 的，我可能是错的，但我认为我们的构建系统不会在 linux 上运行。
第1893章（评论）
第2024章（评论）

zadjii-msft 于 2020-05-26

👎1 👍1

这解释了为什么支持如此有限但不会使这里提出的任何论点无效。 Terminal 的大多数用户是 Server 和 LTSC 用户。终端针对家庭用户的意义何在？最终它会逐渐消失，被锁定在一个非常特定的环境中。现在我回到了cmder ，除非 Terminal 能够设法克服这个问题并在 2020 年尽快可用，否则我也会忘记它。

Kein 于 2020-05-27

Terminal 的大多数用户是 Server 和 LTSC 用户

你有这个说法的证据吗？

zadjii-msft 于 2020-05-27

这个问题可以分为2个问题吗？替代部署机制和最低版本？

sozercan 于 2020-05-27

👍1

还有很多关于“最小版本”的其他线程，所以我将开始在这个线程中将关于最小版本的讨论标记为“离题”。

zadjii-msft 于 2020-05-27

👍2

我们的用例：一所大学在 3.5k Windows 10 桌面上运行长期支持分支，他们确实启用了 Windows 商店，因此他们可以获得终端。我们的管理员（真正喜欢终端并从中受益的管理员）确实拥有可以使用它的 Windows 工作站，但大多数情况下，他们将 RDP 用于许多主要运行 Server 2016 的异构 Windows 服务器，然后使用 MMC 和 PowerShell 进行配置他们。拥有所有这些终端会很棒。

另一种使用模式是 RDP 到单个堡垒 Windows 远程桌面服务器，然后通过 Enter-PSSession 与其他服务器交互。

我们的 Windows Core 服务器很少，因为第三方应用程序堆栈和定期与他们一起进行初始部署的顾问不了解它或应用程序不支持它。

我们有一个配置管理平台，主要用于将 MSI 发送到 Windows 10 和 Server 2016，因此如果它采用可行的格式，将其发送到任何地方都会很容易。

carwyn 于 2020-05-27

👍4

@carwyn在这里也一样。我们的环境往往有 n-1，所以我们支持的客户端刚刚升级到 2016。

我在家里自己的机器上的桌面上预览了 Windows 终端，我很喜欢它。我很想在我们工作中的跳箱上“在生产中”使用它，以供团队使用，但是 Windows Server 2019 的唯一选择意味着我们将不得不等待更长的时间，这对于一个了不起的客户来说有点令人失望我可能会用它来替换我老化的 windows powershell ise。

weiyentan 于 2020-06-11

👍2

对不起，伙计们，我对所有的限制和困难不满意
装置。
我想我找到了我的解决方案。我现在正在使用 mobaXterm。它几乎得到了所有
我需要并且只需要运行安装程序的功能。
生活可以很轻松

Am Do., 11. Juni 2020 um 10:20 Uhr schrieb weiyentan <
通知@github.com>：

gh4chris 于 2020-06-11

此处提到的所有解决方案都不适用于在 Windows Server 2019 上安装。即使使用 scoop，它也会失败并显示“错误至少需要 Windows 10 18362”。

omidkrad 于 2020-06-28

此处提到的所有解决方案都不适用于在 Windows Server 2019 上安装。即使使用 scoop，它也会失败并显示“错误至少需要 Windows 10 18362 ”。

正确的。在Server 2019上不行。2019是基于1809的。至少需要1903。

miketheitguy 于 2020-06-28

此处提到的所有解决方案都不适用于在 Windows Server 2019 上安装。即使使用 scoop，它也会失败并显示“错误至少需要 Windows 10 18362”。

你也可以看看这个问题的最后一条评论：
https://github.com/microsoft/terminal/issues/1386#issuecomment -634933002

tebeco 于 2020-06-28

嗨@DHowett ，关于#6802
如果 Microsoft 商店访问受到限制，下载并双击包不会安装 Microsoft 终端。它显示以下错误

sanket-bhalerao 于 2020-07-08

👍2

和 Sanket 一样的船。我们的 IT 团队（可以理解）非常规避风险，并且重视稳定性而不是新功能。出于安全原因，对 Microsoft Store 的访问被阻止，所以即使我们可以进行更现代的构建（1903、2004），我们似乎也无法从 MSIX 包安装 Windows 终端，除非我们从源代码构建它（我做过一次，但花了很长时间，不想每次都这样做）。

可以理解这一点并没有被忽视，而只是积压。不过，我希望很快就能通过 SCCM（用于客户端）和其他一些方式为 Windows Server 机器部署它。

JongleurNin 于 2020-07-09

@JongleurNin @sanket-bhalerao

如果您具有“下载”功能，这可以正常工作：
我们从 0.9 或 0.10 开始停止从源代码构建，因为现在可以使用：

手动：

https://github.com/microsoft/terminal/releases/latest
下载msixbundle （不要执行）
重命名为 zip
提取它
运行WindowsTerminal.exe
压住他

自动化：

在$PROFILE中创建一个pwsh函数来检查list-release-assets
在这里你想要这个https://api.github.com/repos/microsoft/terminal/releases/latest
你可以使用pwsh ConvertFrom-Json
获取资产列表中以msixbundle结尾的name属性
在browser_download_url字段上使用Invoke-WebRequest $
如果您有NTLM代理，请不要忘记使用Get-Proxy和ProxyUseDefaultCredentials ，因为...公司很有趣
使用Expand-Archive pwsh函数进行解压缩（不确定是否需要显式重命名）
把它放在你的队友的要点中；）

tebeco 于 2020-07-09

需要一个可复制的 exe。控制台等电动工具不需要安装程序。安装程序是一种矫枉过正，请避免它。因此，您无需花费数月的时间进行测试。上次我检查时，Visual Studio 有能力在正式签名的发布模式下生成 exe。
作为高级用户，我们对选择商店作为主要分销模式的决定印象不深。因为，昨天我试图在我的工作机器上安装这个控制台并猜猜是什么，商店配置了我的 Hotmail 帐户，因为它需要一个不是我的工作帐户的 Microsoft 帐户，我可以选择在我的个人 PC 上安装控制台在家里。我需要在我的工作机器上而不是在我的个人机器上使用控制台。
总而言之，只是简单而已。使获取此工具变得容易，以便我们可以使用它。否则，我对使用多年的 ConEmu 感到满意。

好吧，我想关于安装和依赖关系的这么多不合理选择的唯一解释必须与市场/政治相关。我想 MS 希望应用程序商店成为应用程序的唯一合法来源（看起来对 Apple 的商业模式感到饥饿和嫉妒），我想这在某些时候是有道理的，但这也是一条危险的道路。 Windows 用户不是 Apply 用户，也没有那么宽容。
我确信 Win Terminal 团队已经束手无策（好吧，我当然希望这就是原因，让我这么说吧！）

MrM40 于 2020-07-25

👍1

@JongleurNin @sanket-bhalerao

手动：

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

* download `msixbundle` (do not execute it)

* rename to zip

* extract it

* run `WindowsTerminal.exe`

* pin it

这应该适用于 v1.1.2021.0 吗？

zipfile中没有WindowsTerminal.exe ！？

carwyn 于 2020-07-25

您也需要解压缩 sub msix
x86 / x64 / ARM
音乐包一次性发货
这就是你想知道的吗？

这不是明确的，我同意

tebeco 于 2020-07-25

👍1

您也需要解压缩 sub msix

我在发布后就解决了这个问题 :) 这有望在哪些操作系统上运行？我试过 Windows Server 2012R2 和 2016 但没有运气。不确定我是否过于雄心勃勃或者是否需要安装一些东西？

carwyn 于 2020-07-25

您将无法这样做，它已在此 repo 中的多个位置记录和讨论。
WT 依赖于 Windows 本身非常特定的功能，这意味着有一个最小版本

tebeco 于 2020-07-25

👍1

对于想要自动下载的人来说，这是一个非常天真的脚本：

没有完全测试
如果 WT 正在运行，则不支持热插拔 => 使用符号链接可以进行蓝/绿更新？
不设置/更新$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 <strong i="11">@params</strong>

    $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 于 2020-07-25

对于想要自动下载的人来说，这是一个非常天真的脚本：

* 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 <strong i="9">@params</strong>

    $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

为什么要强制使用 PowerShell 7？这使得脚本不太有用。

0x7FFFFFFFFFFFFFFF 于 2020-08-23

你好
非常感谢您注意到它
你想让我为你更新吗？还是你已经在以前的版本上工作了？
（见下文Dev time部分）

为什么？

TL;博士？因为我很懒，我只使用开箱即用的东西

一些上下文，当我花空闲时间试图提供帮助时，我会故意花时间通过提供不可运行的脚本来提供帮助吗？
如果我记得的话，该脚本使用了一个在7.0上添加并在 ~7.0.2/3 中修复的 API，因此它无意打扰任何人
看到TEMP:\驱动器

仍然停留在过时的`powershell`上？

您能否提供相当于TEMP:\驱动器的功能，正如我所说的我很懒，我只是想在空闲时间快速提供帮助
powershell仅在 Windows 上发布，并且现在/将仅限于 5.0 并且不会进化
自从我运行powershell TBH 以来可能已经有 1 年了
这将我们带到了 LTS

使用 LTS

在January 2018中， pwsh (PowerShell Core) 的第一版是 release => 6.0.0
_ pwsh 7.0是当前的 LTS _（于 2020 年 3 月 4 日发货）

此外，您可能已经知道WT需要最小版本的 Windows，所以我可能已经假设（太快）愿意使用wt的消费者可能知道pwsh （powershell核心）自 v6.0 起（2018 年 1 月左右）

开发时间

好吧，因为我倾向于确保我使用它的工具是最新的以避免错误，我没有发现TEMP:\驱动器在以前版本的pwsh上不存在，或者甚至没有试过powershell 。
这个脚本被多个队友使用（可能不是完全相同的脚本），我认为其中一个人注意到了这个问题/更新并提出了这一点。
因此，我们添加了Guard以正确了解要求。

我可以添加有关temp文件夹的输入参数或点击CSharp API 来获取临时文件夹等...
如前所述，我很懒，一个简单的“if() / throw”似乎是在这里提供解决方案的最快方法

奖励积分

另请注意， pwsh 7+在dotnet core运行时上运行，因此它是跨平台的
如果您需要在 Win/Linux/MacOs 上运行脚本，它会更有用
（即使WT只赢）

更新/安装

您是否尝试过更新您的计算机或在这样做时遇到任何问题？我该如何帮助？

管理员对吗？或不

您不需要管理员权限即可安装它

多种方式

如果您在更新计算机方面需要帮助

msix （双击）
msixbundle （双击）
zip （右键单击>提取）
dotnet tool instal -g （复制/粘贴）

官方github

如果你找不到它，这里是官方存储库
https://github.com/powershell/powershell/releases/latest

官方文档

如果您更喜欢部署文档和更多详细信息：
https://github.com/powershell/powershell/releases/tag/v7.0.3

tebeco 于 2020-08-23

@tebeco如果您需要temp:/的替代品，请使用$Env:TEMP 。

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

DHowett 于 2020-08-23

谢谢你的信息

您认为您会接受此存储库中的 PR 以将其作为资产发送吗？
就像 dotnet 团队发布dotnet-install.ps1|sh并创建了一个aka.ms短链接

如果你没问题，我很乐意做 PR

这将解决msixbundle问题，因为到目前为止它在所有已锁定商店的企业环境中都不可用

我大概会问

在哪个文件夹中添加文件
env 变量名称，这样如果没有提供 inout 参数，我们可以或不默认这些var
在哪里更改构建管道以使其成为个人

tebeco 于 2020-08-23

不，谢谢！这意味着我们尚未准备好同意该解决方案的官方支持水平。不过谢谢 :smile:

DHowett 于 2020-08-23

😕3 👎1

我可能错了，我知道短期内不会修复 pb，因为它涉及商店的其他团队等等，你认为这有多准确（大约 6 个月 / 大约 12 个月）？
此外，公司首先锁定Store以避免第三方安装，因此他们可能不想更改其“Windows 基础映像”以安装额外的第三方（是的 Windows 终端是第三部分，除非它在默认的 Windows 安装中提供，这会导致下一期公司没有快速更新“主要映像”（大约 1.5 年的 GAP）

为了给这个问题增加更多痛苦，大约 70% 的时间在公司的一个很难找到/联系/讨论的部分完成（更新基础图像），并且总是会找到不做的“好”理由其他任何人都要求他们这样做，因为他们想确保他们完全拥有一切可以控制的东西（......安装的东西）。

当人们尝试安装WT时，他们可能会放弃，或者尝试在这里查看，并寻找解决方案
他们可能无法在其他地方找到Gist/Repo ，因为他们不知道它存在

置身其中有点奇怪

无法与安全锁定商店/第三方/Windows 安装进行讨论
试图在这里帮助让脚本做一个适当的解决方法，但我知道这不是你的长期目标（假设从现在起 2 年后）

如果有可能从今天开始有一个解决方法，直到未来几年发布的“长期目标”

在发布理想且“可支持”的东西之前，您会在多大程度上推广一种解决方案？
您会将这个 repo 的README更改为要么/都指向托管脚本的 Gist/Repo 吗？
默认情况下，您是否会在每次遇到相同问题时将此主题上的问题打开到此 repo/gist 脚本？

我正在寻找可以从Windows Terminal团队提拔的“中间立场”，但您仍然不会被迫在源头上获得“官方支持”

tebeco 于 2020-08-25

👍4

Terminal: 研究 Windows 终端的替代部署机制

最有用的评论

所有114条评论

MSIX

LTS

从已关闭的问题中复制粘贴：

第1643章（评论）

第1909章（评论）

第841章（评论）

第498章（评论）

第1893章（评论）

第2024章（评论）

手动：

自动化：

手动：

为什么？

仍然停留在过时的`powershell`上？

使用 LTS

开发时间

奖励积分

更新/安装

管理员对吗？或不

多种方式

官方github

官方文档

相关问题

Terminal: 研究 Windows 终端的替代部署机制

最有用的评论

所有114条评论

MSIX

LTS

从已关闭的问题中复制粘贴：

第1643章（评论）

第1909章（评论）

第841章（评论）

第498章（评论）

第1893章（评论）

第2024章（评论）

手动：

自动化：

手动：

为什么 ？

仍然停留在过时的powershell上？

使用 LTS

开发时间

奖励积分

更新/安装

管理员对吗？ 或不

多种方式

官方github

官方文档

相关问题

为什么？

仍然停留在过时的`powershell`上？

管理员对吗？或不