It is hard to find Microsoft.VCLibs.140.00.UWPDesktop #4320

@DHowett-MSFT commented on GitHub (Oct 8, 2019):

The dependencies are not in the package because the dependencies need to be able to be updated without us releasing an update.

@DHowett-MSFT commented on GitHub (Oct 8, 2019): The dependencies are not in the package because the dependencies need to be able to be updated without us releasing an update.

claunia commented

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

Thanks for the quick reply!
Is it possible to attach the dependencies as seperate download for those who has no access to the store?

@EmTschi commented on GitHub (Oct 8, 2019): Thanks for the quick reply! Is it possible to attach the dependencies as seperate download for those who has no access to the store?

claunia commented

@tebeco commented on GitHub (Oct 16, 2019):

The dependencies are not in the package because the dependencies need to be able to be updated without us releasing an update.

@DHowett
i think i've seen FluentTerminal managing to handle that as they ship the dependencies respectively (aside the msixbundle) and an installation script that way the install script managed to properly install everything

it also fixes the part where the store could / update be able to install it later on

that seems like it would be the perfect way for users here.

@tebeco commented on GitHub (Oct 16, 2019): > The dependencies are not in the package because the dependencies need to be able to be updated without us releasing an update. @DHowett i think i've seen FluentTerminal managing to handle that as they ship the dependencies respectively (aside the msixbundle) and an installation script that way the install script managed to properly install everything it also fixes the part where the store could / update be able to install it later on that seems like it would be the perfect way for users here.

claunia commented

@damienleroy commented on GitHub (Nov 13, 2019):

I've got the same issue on my side.
I think the project is too deeply connected to the windows store. It's depend of some package which is not accessible by everyone.
Is it possible to remove the dependance of the store ?

@damienleroy commented on GitHub (Nov 13, 2019): I've got the same issue on my side. I think the project is too deeply connected to the windows store. It's depend of some package which is not accessible by everyone. Is it possible to remove the dependance of the store ?

claunia commented

@tebeco commented on GitHub (Nov 13, 2019):

@ leroyd
For now, in order to use it, I have to manually

build it from vs,
right click publish (shame)
generate my own certificate to sign it during publish
set a specific version, bad because it differs from official package
have to do it twice because there is a bug in the CascadiaPackage.??proj (because of the condition testing pfx existing before you need it so the first publish won’t sign the package ...)
ship it on a corpo shared server
ask user to activate DevMode
then manually run install.ps1

@DHowett-MSFT i’m very interested to know how that msbuild check can be fixed without running the assistant twice

Repro :
git clean -fdx > right click : publish
You’d see for example that the “bundle” combo of the wizard is set to “never” because the pfx check if it exists same for Signing

Also does the .vsconfig works on MsBuild tool 2019 ? So that I can build it from a CI ?

@tebeco commented on GitHub (Nov 13, 2019): @ leroyd For now, in order to use it, I have to manually * build it from vs, * right click publish (shame) * generate my own certificate to sign it during publish * set a specific version, bad because it differs from official package * have to do it twice because there is a bug in the `CascadiaPackage.??proj` (because of the condition testing `pfx` existing before you need it so the first publish won’t sign the package ...) * ship it on a corpo shared server * ask user to activate DevMode * then manually run `install.ps1` @DHowett-MSFT i’m very interested to know how that msbuild check can be fixed without running the assistant twice Repro : `git clean -fdx` > `right click : publish` You’d see for example that the “bundle” combo of the wizard is set to “never” because the `pfx` check if it exists same for Signing Also does the `.vsconfig` works on `MsBuild tool 2019` ? So that I can build it from a CI ?

claunia commented

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

Thanks for your feedback on this everyone. It's very closely related to #3457 but will leave open for now since we're actively looking into several options here.

On the one hand, we'd like to reduce in-package dependencies so that we don't have to ship updates to the Terminal if, in this case, VC140 is updated. But on the other hand, it's not easy to find the correct out-of-package VC140 redist. We're exploring a few things right now. Stay tuned while we figure out some logistics.

@bitcrazed commented on GitHub (Nov 13, 2019): Thanks for your feedback on this everyone. It's very closely related to #3457 but will leave open for now since we're actively looking into several options here. On the one hand, we'd like to reduce in-package dependencies so that we don't have to ship updates to the Terminal if, in this case, VC140 is updated. But on the other hand, it's not easy to find the correct out-of-package VC140 redist. We're exploring a few things right now. Stay tuned while we figure out some logistics.

claunia commented

@tebeco commented on GitHub (Nov 13, 2019):

What about first before changing anything add an artifact here with the content of the output folder of the build

The exact same step I mentioned earlier but from your CI

Update will still not work
probably still require devMode
Some team does NOT have Visual Studio so they cannot build it
It’s just the full folder output to zip and push to github
This will not fix anything but until things are fixed that a good way to embrace users

As I mentioned in a previous comment this is what does FluentTerminal for the exact same issue
And so for it works great for them
another terminal ^^, that can be installed without store access

@tebeco commented on GitHub (Nov 13, 2019): What about first before changing anything add an artifact here with the content of the output folder of the build The exact same step I mentioned earlier but from your CI * Update will still not work * probably still require devMode * Some team does NOT have Visual Studio so they cannot build it It’s just the full folder output to zip and push to github This will not fix anything but until things are fixed that a good way to embrace users As I mentioned in a previous comment this is what does `FluentTerminal` for the exact same issue And so for it works great for them another terminal ^^, that can be installed without store access

claunia commented

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

@tebeco Appreciate your thoughts here, but we're keen to try to minimize/avoid shipping others' dependencies and binaries for a variety of (predominantly servicing) reasons. We're discussing with several teams as I type and will update this thread with info once we've arrived at a workable solution.

@bitcrazed commented on GitHub (Nov 15, 2019): @tebeco Appreciate your thoughts here, but we're keen to try to minimize/avoid shipping others' dependencies and binaries for a variety of (predominantly servicing) reasons. We're discussing with several teams as I type and will update this thread with info once we've arrived at a workable solution.

claunia commented

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

Thx a lot for the “insight view”
Will wait “patiently” here ^^
For now I’ll continue to do manual build for our teammates 😆

@tebeco commented on GitHub (Nov 15, 2019): Thx a lot for the “insight view” Will wait “patiently” here ^^ For now I’ll continue to do manual build for our teammates 😆 ![6F288C93-B88E-45C7-B1E3-4C1137ADB1B5](https://user-images.githubusercontent.com/2266487/68970810-6ebe6500-07e8-11ea-9db2-615e58b4152e.gif)

claunia commented

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

So my issue was closed and pointed to this thread. However, I see no resolution.

I installed the UWPDesktop from the release notes, and still cannot install terminal.

@gbargsley commented on GitHub (Feb 7, 2020): So my issue was closed and pointed to this thread. However, I see no resolution. I installed the UWPDesktop from the release notes, and still cannot install terminal.

claunia commented

2026-01-30 23:43:53 +00:00

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

So far i found absolutly no workaround at work either
The last WindowsTerminal_0.8.10261.0_x64__8wekyb3d8bbwe msixbundle does install but the app crash, same if i install from chocolatey

result is here : https://github.com/microsoft/terminal/issues/4424
issue was closed

======================================================================================================
@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 The last `WindowsTerminal_0.8.10261.0_x64__8wekyb3d8bbwe` `msixbundle` does install but the app crash, same if i install from `chocolatey` result is here : https://github.com/microsoft/terminal/issues/4424 issue was closed ====================================================================================================== @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

@WSLUser commented on GitHub (Feb 12, 2020):

I get the same thing as @tebeco on an offline Windows 10 Enterprise host. From what I've been able to determine, it seems like a permissions issue. If you manually try to go to the directory in file explorer, you can not, even as administrator. I changed ownership to the local Administrators group and provided authenticated users group read access but that didn't seem to do the trick. This is on 1909 and sideloading is enabled. I did install everything listed on the install notes.

@WSLUser commented on GitHub (Feb 12, 2020): I get the same thing as @tebeco on an offline Windows 10 Enterprise host. From what I've been able to determine, it seems like a permissions issue. If you manually try to go to the directory in file explorer, you can not, even as administrator. I changed ownership to the local Administrators group and provided authenticated users group read access but that didn't seem to do the trick. This is on 1909 and sideloading is enabled. I did install everything listed on the install notes.

claunia commented

2026-01-30 23:43:53 +00:00

@WSLUser commented on GitHub (Feb 12, 2020):

@DHowett I thought of a potential solution that does involve another team in MS. It's probably been thought about already but just in case: Just like Office can receive updates through Windows Update but is an external download/install, so too can Windows Terminal do the same. Make sure it can be available for WSUS and then you'll be able to push this great app to anybody running the required build version of Windows (just be sure Server 2016 and 2019 are also supported).

@WSLUser commented on GitHub (Feb 12, 2020): @DHowett I thought of a potential solution that does involve another team in MS. It's probably been thought about already but just in case: Just like Office can receive updates through Windows Update but is an external download/install, so too can Windows Terminal do the same. Make sure it can be available for WSUS and then you'll be able to push this great app to anybody running the required build version of Windows (just be sure Server 2016 and 2019 are also supported).

claunia commented

2026-01-30 23:43:53 +00:00

@4integration commented on GitHub (Feb 14, 2020):

Still the same issue with v0.9.433.0
My issue report: https://github.com/microsoft/terminal/issues/4562

@4integration commented on GitHub (Feb 14, 2020): Still the same issue with v0.9.433.0 My issue report: https://github.com/microsoft/terminal/issues/4562

claunia commented

2026-01-30 23:43:54 +00:00

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

(very sorry for the images size, as depending on you extensions, they could be rendered way bigger than i though)

I do confirm that it's still an issue with 0.9.x msixbundle.

I think both comments from @WSLUser are spots on :

I get the same thing as @tebeco on an offline Windows 10 Enterprise host. From what I've been able to determine, it seems like a permissions issue. If you manually try to go to the directory in file explorer, you can not, even as administrator. I changed ownership to the local Administrators group and provided authenticated users group read access but that didn't seem to do the trick. This is on 1909 and sideloading is enabled. I did install everything listed on the install notes.

@DHowett I thought of a potential solution that does involve another team in MS. It's probably been thought about already but just in case: Just like Office can receive updates through Windows Update but is an external download/install, so too can Windows Terminal do the same. Make sure it can be available for WSUS and then you'll be able to push this great app to anybody running the required build version of Windows (just be sure Server 2016 and 2019 are also supported).

as @bitcrazed said, it's being discussed, which is great
Thought, i would love to know, is it possible to simply publish artifacts, while a concensus / decision is made ?

For now i had to manually build it myself for co-worker, but since 0.8.x it stopped building while following this instruction of this repository
It seems that this #1386 suggest to apply "the same" idea => install from build artifiacts
see : https://github.com/microsoft/terminal/issues/1386#issuecomment-506419057

Can it be pushed to AzureDevops Artifacts for example ?

@tebeco commented on GitHub (Feb 14, 2020): (very sorry for the images size, as depending on you extensions, they could be rendered way bigger than i though) I do confirm that it's still an issue with `0.9.x` msixbundle. I think both comments from @WSLUser are spots on : > I get the same thing as @tebeco on an offline Windows 10 Enterprise host. From what I've been able to determine, it seems like a permissions issue. If you manually try to go to the directory in file explorer, you can not, even as administrator. I changed ownership to the local Administrators group and provided authenticated users group read access but that didn't seem to do the trick. This is on 1909 and sideloading is enabled. I did install everything listed on the install notes. > @DHowett I thought of a potential solution that does involve another team in MS. It's probably been thought about already but just in case: Just like Office can receive updates through Windows Update but is an external download/install, so too can Windows Terminal do the same. Make sure it can be available for WSUS and then you'll be able to push this great app to anybody running the required build version of Windows (just be sure Server 2016 and 2019 are also supported). as @bitcrazed said, it's being discussed, which is great Thought, i would love to know, is it possible to simply publish artifacts, while a concensus / decision is made ? For now i had to manually build it myself for co-worker, but since `0.8.x` it stopped building while following this instruction of this repository It seems that this #1386 suggest to apply "the same" idea => install from build artifiacts see : https://github.com/microsoft/terminal/issues/1386#issuecomment-506419057 ![image](https://user-images.githubusercontent.com/2266487/74522152-f9fbe380-4f1a-11ea-9542-2828c19c90eb.png) ![image](https://user-images.githubusercontent.com/2266487/74522612-d08f8780-4f1b-11ea-921b-f97b533d629d.png) Can it be pushed to AzureDevops Artifacts for example ?

claunia commented

2026-01-30 23:43:54 +00:00

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

See if this helps https://github.com/microsoft/terminal/issues/1386#issuecomment-591177598

@deskoh commented on GitHub (Feb 26, 2020): See if this helps https://github.com/microsoft/terminal/issues/1386#issuecomment-591177598

claunia commented

2026-01-30 23:43:54 +00:00

@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

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

I'm not sure if this will help or not, but while trying to get things installed without using the Microsoft Store (disabled by GPO in my company), I ran into the following:

I installed the package from the Microsoft site. The details of the file (details tab in file properties) indicate the version is 14.0.24222.0
The installation via Chocolatey fails and provides an ActivityID. Looking at the logs for that activity has a message like

Windows cannot install package Microsoft.WindowsTerminal_0.9.433.0_x64__8wekyb3d8bbwe because this package depends on a framework
that could not be found. Provide the framework "Microsoft.VCLibs.140.00" 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" currently installed are:
{Microsoft.VCLibs.140.00_14.0.26706.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00_14.0.26706.0_x86__8wekyb3d8bbwe}`

So, it seems like the problem may be that the required version is higher than what is being provided by the download page, however, the version after installation doesn't match the file version info, so I'm not sure if there is a different version string that is being looked for.

@jheiselman commented on GitHub (Feb 26, 2020): I'm not sure if this will help or not, but while trying to get things installed without using the Microsoft Store (disabled by GPO in my company), I ran into the following: 1. I installed the package from the Microsoft site. The details of the file (details tab in file properties) indicate the version is 14.0.24222.0 2. The installation via Chocolatey fails and provides an ActivityID. Looking at the logs for that activity has a message like > Windows cannot install package Microsoft.WindowsTerminal_0.9.433.0_x64__8wekyb3d8bbwe because this package depends on a framework > that could not be found. Provide the framework "Microsoft.VCLibs.140.00" 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" currently installed are: > {Microsoft.VCLibs.140.00_14.0.**26706**.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00_14.0.**26706**.0_x86__8wekyb3d8bbwe}` So, it seems like the problem _may_ be that the required version is higher than what is being provided by the download page, however, the version after installation doesn't match the file version info, so I'm not sure if there is a different version string that is being looked for.

claunia commented

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

Did a little bit more digging. I'm not super familiar with Windows package development.
Here is a summary of file version identifiers I found:
From the Details tab of the file properties of the downloaded .exe: 14.0.24222.0
From the APPX Retail x64 version: 14.0.24217.0
From the APPX Debug x64 version: 14.0.24222.0
From the AppPackageLog:
Min Version=14.0.27323.0
List of installed frameworks: 14.0.26706.0

So, there are many version numbers that are all very similar and I know that it's all confusing me. Perhaps we could get which one of these versions we should be looking for and which ones are red herrings. Otherwise, all I can figure out is that the redist package being used in development isn't publicly available at this time, so no one outside of Microsoft will be able to install this package without building it ourselves (which isn't an option for me).

@jheiselman commented on GitHub (Feb 26, 2020): Did a little bit more digging. I'm not super familiar with Windows package development. Here is a summary of file version identifiers I found: From the Details tab of the file properties of the downloaded .exe: 14.0.24222.0 From the APPX Retail x64 version: 14.0.24217.0 From the APPX Debug x64 version: 14.0.24222.0 From the AppPackageLog: Min Version=14.0.27323.0 List of installed frameworks: 14.0.26706.0 So, there are many version numbers that are all very similar and I know that it's all confusing me. Perhaps we could get which one of these versions we should be looking for and which ones are red herrings. Otherwise, all I can figure out is that the redist package being used in development isn't publicly available at this time, so no one outside of Microsoft will be able to install this package without building it ourselves (which isn't an option for me).

claunia commented

@thomas-ashcraft commented on GitHub (Mar 11, 2020):

I think the problem is much simpler and stupider.

Intro

Trying to install "The Terminal" (for example by choco install microsoft-windows-terminal), it throws an error where it trying to find a Microsoft.VCLibs.140.00.UWPDesktop platform, at least 14.0.27323.0 version. But win10 in many (or most) cases has older version. For example, Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe. And everyone looked for those digits: 14.0.26905 vs 14.0.27323. You can even check that like this:

> Get-AppxPackage -allusers *Microsoft.VCLibs.140.00.UWPDesktop* | Select Name, PackageFullName

Name                               PackageFullName
----                               ---------------
Microsoft.VCLibs.140.00.UWPDesktop Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe

Where we should look instead

> Get-AppxPackage -allusers *Microsoft.VCLibs.140.00* | Select Name, PackageFullName

Name                               PackageFullName
----                               ---------------
Microsoft.VCLibs.140.00.UWPDesktop Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe
Microsoft.VCLibs.140.00            Microsoft.VCLibs.140.00_14.0.27323.0_x64__8wekyb3d8bbwe
Microsoft.VCLibs.140.00            Microsoft.VCLibs.140.00_14.0.27323.0_x86__8wekyb3d8bbwe
Microsoft.VCLibs.140.00            Microsoft.VCLibs.140.00_14.0.26706.0_x64__8wekyb3d8bbwe
Microsoft.VCLibs.140.00            Microsoft.VCLibs.140.00_14.0.26706.0_x86__8wekyb3d8bbwe

I think its pretty self explanatory. But in case... The Terminal requirement seeks for "YetAnotherCrap.UWPDesktop_100500". The Microsoft provides us only with "YetAnotherCrap_100500". Without that UWPDesktop part in the name.

P.S.

Yes, I downloaded those vc140 libs also by link from readme.md.
Yes, I tried to install every piece (terminal, libs...) throug choco and/or through Windows Store. Tried every approach.
Yes, I tried to delete that ugly old UWPDesktop_14.0.26905 version. But...

> Remove-AppxPackage -Package "Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe"

...cmdlet says that package are dependency for Microsoft.DesktopAppInstaller and Microsoft.MicrosoftOfficeHub, so it wont be deleted in any case. Means windows are totally not able to make it, because there is no force-mode to ignore dependencies.

Also... it seems you cannot remove older versions of packages. I tried with Microsoft.VCLibs.140.00_14.0.26706.0 and it just not working. It does not throws any errors or anything. Adding verbose key, adds only 2 strings: "Performing removing" and "removing stopped".

@thomas-ashcraft commented on GitHub (Mar 11, 2020): I think the problem is much simpler and stupider. ### Intro Trying to install "The Terminal" (for example by ```choco install microsoft-windows-terminal```), it throws an error where it trying to find a ```Microsoft.VCLibs.140.00.UWPDesktop``` platform, at least ```14.0.27323.0``` version. But win10 in many (or most) cases has older version. For example, ```Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe```. And everyone looked for those digits: 14.0.**26905** vs 14.0.**27323**. You can even check that like this: ```powershell > Get-AppxPackage -allusers *Microsoft.VCLibs.140.00.UWPDesktop* | Select Name, PackageFullName Name PackageFullName ---- --------------- Microsoft.VCLibs.140.00.UWPDesktop Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe ``` ### Where we should look instead ```powershell > Get-AppxPackage -allusers *Microsoft.VCLibs.140.00* | Select Name, PackageFullName Name PackageFullName ---- --------------- Microsoft.VCLibs.140.00.UWPDesktop Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00 Microsoft.VCLibs.140.00_14.0.27323.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00 Microsoft.VCLibs.140.00_14.0.27323.0_x86__8wekyb3d8bbwe Microsoft.VCLibs.140.00 Microsoft.VCLibs.140.00_14.0.26706.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00 Microsoft.VCLibs.140.00_14.0.26706.0_x86__8wekyb3d8bbwe ``` I think its pretty self explanatory. But in case... The Terminal requirement seeks for "YetAnotherCrap.UWPDesktop_100500". The Microsoft provides us only with "YetAnotherCrap_100500". Without that UWPDesktop part in the name. ### P.S. Yes, I downloaded those vc140 libs also by link from readme.md. Yes, I tried to install every piece (terminal, libs...) throug choco and/or through Windows Store. Tried every approach. Yes, I tried to delete that ugly old ```UWPDesktop_14.0.26905``` version. But... ```powershell > Remove-AppxPackage -Package "Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe" ``` ...cmdlet says that package are dependency for ```Microsoft.DesktopAppInstaller``` and ```Microsoft.MicrosoftOfficeHub```, so it wont be deleted in any case. Means windows are totally not able to make it, because there is no force-mode to ignore dependencies. Also... it seems you cannot remove older versions of packages. I tried with ```Microsoft.VCLibs.140.00_14.0.26706.0``` and it just not working. It does not throws any errors or anything. Adding verbose key, adds only 2 strings: "Performing removing" and "removing stopped".

claunia commented

@tebeco commented on GitHub (Mar 11, 2020):

edit:
the previous workaround here could have corrupted more than it actually fixed.

as explained here : https://github.com/microsoft/terminal/issues/3097#issuecomment-597706462

the end result is similar to

download msixbundle
unzip
run it

the issue is that you need to be sure the dependencies are properly installed

@tebeco commented on GitHub (Mar 11, 2020): edit: the previous workaround here could have corrupted more than it actually fixed. as explained here : https://github.com/microsoft/terminal/issues/3097#issuecomment-597706462 the end result is similar to * download msixbundle * unzip * run it the issue is that you need to be sure the dependencies are properly installed

claunia commented

@thomas-ashcraft commented on GitHub (Mar 11, 2020):

And another one clue about "UWPDesktop" part at name.
Part of AppxManifest.xml inside CascadiaPackage_0.9.433.0_x64.msix that inside Microsoft.WindowsTerminal_0.9.433.0_8wekyb3d8bbwe.msixbundle.

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>

I'm not sure this is the only reason, but there is no Optional flag at <PackageDependency> tags. So accordingly to official documentation this is looks like it is not only just making difference between names with and without UWPDesktop part (as I wrote at comment above), but also trying to require them both!

@thomas-ashcraft commented on GitHub (Mar 11, 2020): And another one clue about "UWPDesktop" part at name. Part of ```AppxManifest.xml``` inside ```CascadiaPackage_0.9.433.0_x64.msix``` that inside ```Microsoft.WindowsTerminal_0.9.433.0_8wekyb3d8bbwe.msixbundle```. ```XML <Dependencies> <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" /> <PackageDependency Name="Microsoft.VCLibs.140.00" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" /> <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" /> </Dependencies> ``` I'm not sure this is the only reason, but there is no ```Optional``` flag at ```<PackageDependency>``` tags. So accordingly to [official documentation](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-packagedependency) this is looks like it is not only just making difference between names with and without ```UWPDesktop``` part (as I wrote at comment above), but also **trying to require them both**!

claunia commented

@DHowett-MSFT commented on GitHub (Mar 11, 2020):

@TeBeCo what you’ve described is the same as unzipping the MSIXBundle and using the exe inside it with the added step of corrupting the permissions on your system. If you’re going to go to all that effort, just unzip the msix bundle like I suggested to you in the original issue you filed 😄

@DHowett-MSFT commented on GitHub (Mar 11, 2020): @TeBeCo what you’ve described is the same as unzipping the MSIXBundle and using the exe inside it with the added step of corrupting the permissions on your system. If you’re going to go to all that effort, just unzip the msix bundle like I suggested to you in the original issue you filed 😄

claunia commented

@tebeco commented on GitHub (Mar 11, 2020):

ahhh i forgot that ^^
maybe that was when the VCLibs were not installed and was still stuck because the msix did not contained or installed the dependencies IIRC

sorry about that

yeah for the permissions that's what i was afraid of.
that's why i tried to write huge disclaimer as it's probably not recommended at all but was not sure before asking here to be honest

i'll go ok and try an unzip on future version

do you want me to edit or remove the previous comment to avoid user to corrupt their own permissions ?

i guess it's normal to be denied on that folder ?
even for normal installation? (i mean no special GPO / store not locked down)
if it's normal is the "network access denied" know ?
and why do the "network error" if fixed by a folder right ^^

i'm trying to understand things part by part as i don't have the full picture in my head

@tebeco commented on GitHub (Mar 11, 2020): ahhh i forgot that ^^ maybe that was when the VCLibs were not installed and was still stuck because the msix did not contained or installed the dependencies IIRC sorry about that yeah for the permissions that's what i was afraid of. that's why i tried to write huge disclaimer as it's probably not recommended at all but was not sure before asking here to be honest i'll go ok and try an unzip on future version #### do you want me to edit or remove the previous comment to avoid user to corrupt their own permissions ? i guess it's normal to be denied on that folder ? even for normal installation? (i mean no special GPO / store not locked down) if it's normal is the "network access denied" know ? and why do the "network error" if fixed by a folder right ^^ i'm trying to understand things part by part as i don't have the full picture in my head

claunia commented

@DHowett-MSFT commented on GitHub (Mar 11, 2020):

@tebeco please do. That folder is managed by the windows application installer, and it's not intended to be edited by the local administrator. I'm not certain what could happen, but I would be worried to find out 😄

@DHowett-MSFT commented on GitHub (Mar 11, 2020): @tebeco please do. That folder is managed by the windows application installer, and it's not intended to be edited by the local administrator. I'm not certain what could happen, but I would be worried to find out :smile:

claunia commented

@tebeco commented on GitHub (Mar 11, 2020):

(done)
do you have further info on the others questions regarding the current behavior / error msg etc ... at the end of this comment :
https://github.com/microsoft/terminal/issues/3097#issuecomment-597796444

because i wonder if the unzip would fix the dependencies issue, i might have installed them manually
or the installation might install them and only after unzipping could work

@tebeco commented on GitHub (Mar 11, 2020): (done) do you have further info on the others questions regarding the current behavior / error msg etc ... at the end of this comment : https://github.com/microsoft/terminal/issues/3097#issuecomment-597796444 because i wonder if the unzip would fix the dependencies issue, i might have installed them manually or the installation might install them and only after unzipping could work

claunia commented

@DHowett-MSFT commented on GitHub (Mar 11, 2020):

If I knew why you were hitting a "network error" installing and launching packaged applications, you'd be the first to know 😄 it's a mystery to all of us.

@DHowett-MSFT commented on GitHub (Mar 11, 2020): If I knew why you were hitting a "network error" installing and launching packaged applications, you'd be the first to know :smile: it's a mystery to all of us.

claunia commented

@tebeco commented on GitHub (Mar 11, 2020):

what can i do to help ?

if you do have a custom build or msixbundle that your team can send on another feed or whatever with more logs
can i trace it somehow ?

i looked in the EventViewer but was not lucky

i'm very very much whiling to help
and i might have a spare laptop at work to serve as a dummy for this test (at least for now)

just tell me what can i do. i would even suggest a debug session but the firewall here is kinda nasty
and not sure if i can use the "support card" for that to escaladate as it's absolutely not blocking anyone ;) :trollface:

@tebeco commented on GitHub (Mar 11, 2020): what can i do to help ? if you do have a custom build or msixbundle that your team can send on another feed or whatever with more logs can i trace it somehow ? i looked in the EventViewer but was not lucky i'm very very much whiling to help and i might have a spare laptop at work to serve as a dummy for this test (at least for now) just tell me what can i do. i would even suggest a debug session but the firewall here is kinda nasty and not sure if i can use the "support card" for that to escaladate as it's absolutely not blocking anyone ;) :trollface:

claunia commented

@kevinbowman commented on GitHub (Mar 31, 2020):

Any news on this, I have the same issue running 1903. I can't install from the Store, but downloaded the MSIX and Choco pkg to no avail. Unzipping the MSIX and running the exe does work through (apart from AZure CLI not working so far). Can we at least remove the dependency so the install completes and go from there??

I have these VCLibs with after installing this https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/

I also have VS2019 installed too.

@kevinbowman commented on GitHub (Mar 31, 2020): Any news on this, I have the same issue running 1903. I can't install from the Store, but downloaded the MSIX and Choco pkg to no avail. Unzipping the MSIX and running the exe does work through (apart from AZure CLI not working so far). Can we at least remove the dependency so the install completes and go from there?? I have these VCLibs with after installing this https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/ ![image](https://user-images.githubusercontent.com/19746567/78072332-dd1a5300-7396-11ea-9851-81a98ad4ad75.png) I also have VS2019 installed too.

claunia commented

@bitcrazed commented on GitHub (Mar 31, 2020):

Reassigning to @DHowett and @cinnamon-msft

FWIW, you may be missing some VCLibs.140 UWPDesktop packages:

The Win10 SDK alone does not install some of these packages.

Please bear with us while we figure some of this out - there's a complex dance in-play.

@bitcrazed commented on GitHub (Mar 31, 2020): Reassigning to @DHowett and @cinnamon-msft FWIW, you may be missing some VCLibs.140 UWPDesktop packages: ![image](https://user-images.githubusercontent.com/961950/78074220-2b0f6680-7357-11ea-861e-07d6cbb8e5c5.png) The Win10 SDK alone does not install some of these packages. Please bear with us while we figure some of this out - there's a complex dance in-play.

claunia commented

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

I am using chocolatey to install terminal and also encountered this error. The strange thing is: I literally just setup my machine this way last weekend (from a clean win10 install) and it worked fine, but now it's not on a reinstall (another win10 clean install). The particularly odd thing is that choco did successfully install the vcredis140 package! Errors and confirmation all below. The UWPDesktop version I have is behind what is looked for with terminal -- but I even tried installing the "Desktop Bridge VC++ v14 Redistributable Package" mentioned in the README and it did not seem to change anything. I literally used this same process successfully only 5 days ago so I am mighty confused.

Error from choco install terminal (I use upgrade to install):

PS C:\Windows\system32> choco upgrade -y microsoft-windows-terminal
Chocolatey v0.10.15
2 validations performed. 1 success(es), 1 warning(s), and 0 error(s).

Validation Warnings:
 - A pending system reboot request has been detected, however, this is
   being ignored due to the current Chocolatey configuration.  If you
   want to halt when this occurs, then either set the global feature
   using:
     choco feature enable -name=exitOnRebootDetected
   or pass the option --exit-when-reboot-detected.

Upgrading the following packages:
microsoft-windows-terminal
By upgrading you accept licenses for the packages.
microsoft-windows-terminal is not installed. Installing...
Progress: Downloading microsoft-windows-terminal 0.10.781.0... 100%
Progress: Downloading microsoft-windows-terminal 0.10.781.0... 100%

microsoft-windows-terminal v0.10.781.0 [Approved]
microsoft-windows-terminal package files upgrade completed. Performing other installation steps.
Progress: 0% - Processing                                                                                              ERROR: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Deployment failed with HRESULT: 0x80073CF3, Package failed updates, dependency or conflict validation.

Windows cannot install package Microsoft.WindowsTerminal_0.10.781.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.10.781.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_x64__8wekyb3d8bbwe}

NOTE: For additional information, look for [ActivityId] b2d4ad61-09bb-0006-23c9-d4b2bb09d601 in the Event Log or use the command line Get-AppPackageLog -ActivityID b2d4ad61-09bb-0006-23c9-d4b2bb09d601

The upgrade of microsoft-windows-terminal was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\microsoft-windows-terminal\tools\chocolateyInstall.ps1'.
 See log for details.

Chocolatey upgraded 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures
 - microsoft-windows-terminal (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\microsoft-windows-terminal\tools\chocolateyInstall.ps1'.
 See log for details.

Here is the status of my vcredist:

PS C:\Windows\system32> choco upgrade -y vcredist140
Chocolatey v0.10.15
2 validations performed. 1 success(es), 1 warning(s), and 0 error(s).

Validation Warnings:
 - A pending system reboot request has been detected, however, this is
   being ignored due to the current Chocolatey configuration.  If you
   want to halt when this occurs, then either set the global feature
   using:
     choco feature enable -name=exitOnRebootDetected
   or pass the option --exit-when-reboot-detected.

Upgrading the following packages:
vcredist140
By upgrading you accept licenses for the packages.
vcredist140 v14.24.28127.4 is the latest version available based on your source(s).

Chocolatey upgraded 0/1 packages.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

With these packages, using the suggested command:

PS C:\Windows\system32> Get-AppxPackage -AllUsers *vclibs* | sort PackageFullName | Select Name, Version, PackageFullName

Name                               Version      PackageFullName
----                               -------      ---------------
Microsoft.VCLibs.140.00.UWPDesktop 14.0.26905.0 Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe
Microsoft.VCLibs.140.00            14.0.27810.0 Microsoft.VCLibs.140.00_14.0.27810.0_x64__8wekyb3d8bbwe
Microsoft.VCLibs.140.00            14.0.27810.0 Microsoft.VCLibs.140.00_14.0.27810.0_x86__8wekyb3d8bbwe

……….
At this point I have tried forcing the next version of vcredist (not yet approved) with:
choco install -y vcredist140 --version=14.25.28508.3

But honestly, at this point I'm simply curious: where does one get this new version from?
……
Well, I found out: if I install ubuntu for WSL from the store, then I get the correct version of uwpdesktop. Quite the fix...

@rogusdev commented on GitHub (Apr 3, 2020): I am using chocolatey to install terminal and also encountered this error. The strange thing is: I literally just setup my machine this way last weekend (from a clean win10 install) and it worked fine, but now it's not on a reinstall (another win10 clean install). The particularly odd thing is that choco did successfully install the vcredis140 package! Errors and confirmation all below. The UWPDesktop version I have is behind what is looked for with terminal -- but I even tried installing the "Desktop Bridge VC++ v14 Redistributable Package" mentioned in the README and it did not seem to change anything. I literally used this same process successfully only 5 days ago so I am mighty confused. Error from choco install terminal (I use upgrade to install): ``` PS C:\Windows\system32> choco upgrade -y microsoft-windows-terminal Chocolatey v0.10.15 2 validations performed. 1 success(es), 1 warning(s), and 0 error(s). Validation Warnings: - A pending system reboot request has been detected, however, this is being ignored due to the current Chocolatey configuration. If you want to halt when this occurs, then either set the global feature using: choco feature enable -name=exitOnRebootDetected or pass the option --exit-when-reboot-detected. Upgrading the following packages: microsoft-windows-terminal By upgrading you accept licenses for the packages. microsoft-windows-terminal is not installed. Installing... Progress: Downloading microsoft-windows-terminal 0.10.781.0... 100% Progress: Downloading microsoft-windows-terminal 0.10.781.0... 100% microsoft-windows-terminal v0.10.781.0 [Approved] microsoft-windows-terminal package files upgrade completed. Performing other installation steps. Progress: 0% - Processing ERROR: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Deployment failed with HRESULT: 0x80073CF3, Package failed updates, dependency or conflict validation. Windows cannot install package Microsoft.WindowsTerminal_0.10.781.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.10.781.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_x64__8wekyb3d8bbwe} NOTE: For additional information, look for [ActivityId] b2d4ad61-09bb-0006-23c9-d4b2bb09d601 in the Event Log or use the command line Get-AppPackageLog -ActivityID b2d4ad61-09bb-0006-23c9-d4b2bb09d601 The upgrade of microsoft-windows-terminal was NOT successful. Error while running 'C:\ProgramData\chocolatey\lib\microsoft-windows-terminal\tools\chocolateyInstall.ps1'. See log for details. Chocolatey upgraded 0/1 packages. 1 packages failed. See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log). Failures - microsoft-windows-terminal (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\microsoft-windows-terminal\tools\chocolateyInstall.ps1'. See log for details. ``` Here is the status of my vcredist: ``` PS C:\Windows\system32> choco upgrade -y vcredist140 Chocolatey v0.10.15 2 validations performed. 1 success(es), 1 warning(s), and 0 error(s). Validation Warnings: - A pending system reboot request has been detected, however, this is being ignored due to the current Chocolatey configuration. If you want to halt when this occurs, then either set the global feature using: choco feature enable -name=exitOnRebootDetected or pass the option --exit-when-reboot-detected. Upgrading the following packages: vcredist140 By upgrading you accept licenses for the packages. vcredist140 v14.24.28127.4 is the latest version available based on your source(s). Chocolatey upgraded 0/1 packages. See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log). ``` With these packages, using the suggested command: ``` PS C:\Windows\system32> Get-AppxPackage -AllUsers *vclibs* | sort PackageFullName | Select Name, Version, PackageFullName Name Version PackageFullName ---- ------- --------------- Microsoft.VCLibs.140.00.UWPDesktop 14.0.26905.0 Microsoft.VCLibs.140.00.UWPDesktop_14.0.26905.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00 14.0.27810.0 Microsoft.VCLibs.140.00_14.0.27810.0_x64__8wekyb3d8bbwe Microsoft.VCLibs.140.00 14.0.27810.0 Microsoft.VCLibs.140.00_14.0.27810.0_x86__8wekyb3d8bbwe ``` ………. At this point I have tried forcing the next version of vcredist (not yet approved) with: choco install -y vcredist140 --version=14.25.28508.3 But honestly, at this point I'm simply curious: where does one get this new version from? …… Well, I found out: if I install ubuntu for WSL from the store, then I get the correct version of uwpdesktop. Quite the fix...

claunia commented

x86:
http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/7940bc27-6f7a-4b37-949b-4c8d9ed94460?P1=1587105490&P2=402&P3=2&P4=AtQJnsmggRcHcsZyjMqotvtXkl8BtKNjjNTLNMXElMvbb9bW9BzGGAt1R0abu%2ff55938xk%2fSQvuhGqi8Do4kow%3d%3d
http://dl.delivery.mp.microsoft.com/filestreamingservice/files/1d146565-6dae-41ce-a1d7-febc36317f36

@atom0s commented on GitHub (Apr 17, 2020):

The needed packages can be downloaded from the Microsoft Store currently here:
https://www.microsoft.com/store/productId/9NBLGGH4RV3K

For whatever reason this page is hidden. The direct links currently are:

x64:
http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/0e19f025-0004-48c2-b699-ee1a275389b7?P1=1587105510&P2=402&P3=2&P4=VDFc2TYZIE76bGINYMsEM4%2fuLyj6Q9aWopsazPUOFeN9O%2bWZ2VweF%2fddYWmYAsEPf8fxw3z9GJ1y6ZoLsNd14w%3d%3d
http://dl.delivery.mp.microsoft.com/filestreamingservice/files/7d52a905-fc42-4c82-a642-70b3bede55dc

ARM:
http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/c14c0261-8f5d-432c-81ca-3518a53c9581?P1=1587105510&P2=402&P3=2&P4=FjeknMnvJynzKWZYBeAIihMNefCIjfLAYJ6xXMXN8IVbdmQJ97bFaz395nYlKl%2bMd5mt%2fyS4GfvuYI%2f8HcBMhQ%3d%3d
http://dl.delivery.mp.microsoft.com/filestreamingservice/files/67fb1b12-2236-4b18-8079-f3f3cd27a707

ARM64:
http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/0b0a31d6-85a8-4f63-ad1a-6a31afe4ee1c?P1=1587105510&P2=402&P3=2&P4=EApKlQwATjqsOibgA87H69FzpEU%2fCFOQ%2fARRv9J82CUe6a4CtVAQBcDUk1mCV4JK3Ghg62UWi0fX2MS0F7Wq%2fA%3d%3d
http://dl.delivery.mp.microsoft.com/filestreamingservice/files/83533985-0915-4337-b849-532913e9d544

I am unsure of these links being timed or session-based, so if they do expire, here is how to get them again:

Visit: https://store.rg-adguard.net/ (This is a third-party site, disable ads and javascript before visiting to be sure.)
Select URL (link) from the drop down.
Enter: https://www.microsoft.com/store/productId/9NBLGGH4RV3K

This will pull real/valid links from Microsofts store. You can verify the links before downloading them to trust their locations as needed. The appx's are downloaded from Microsofts servers directly, so they are safe.

Doing this will get you the needed requirement to get this installed and working.

@atom0s commented on GitHub (Apr 17, 2020): The needed packages can be downloaded from the Microsoft Store currently here: https://www.microsoft.com/store/productId/9NBLGGH4RV3K For whatever reason this page is hidden. The direct links currently are: x86: http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/7940bc27-6f7a-4b37-949b-4c8d9ed94460?P1=1587105490&P2=402&P3=2&P4=AtQJnsmggRcHcsZyjMqotvtXkl8BtKNjjNTLNMXElMvbb9bW9BzGGAt1R0abu%2ff55938xk%2fSQvuhGqi8Do4kow%3d%3d http://dl.delivery.mp.microsoft.com/filestreamingservice/files/1d146565-6dae-41ce-a1d7-febc36317f36 x64: http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/0e19f025-0004-48c2-b699-ee1a275389b7?P1=1587105510&P2=402&P3=2&P4=VDFc2TYZIE76bGINYMsEM4%2fuLyj6Q9aWopsazPUOFeN9O%2bWZ2VweF%2fddYWmYAsEPf8fxw3z9GJ1y6ZoLsNd14w%3d%3d http://dl.delivery.mp.microsoft.com/filestreamingservice/files/7d52a905-fc42-4c82-a642-70b3bede55dc ARM: http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/c14c0261-8f5d-432c-81ca-3518a53c9581?P1=1587105510&P2=402&P3=2&P4=FjeknMnvJynzKWZYBeAIihMNefCIjfLAYJ6xXMXN8IVbdmQJ97bFaz395nYlKl%2bMd5mt%2fyS4GfvuYI%2f8HcBMhQ%3d%3d http://dl.delivery.mp.microsoft.com/filestreamingservice/files/67fb1b12-2236-4b18-8079-f3f3cd27a707 ARM64: http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/0b0a31d6-85a8-4f63-ad1a-6a31afe4ee1c?P1=1587105510&P2=402&P3=2&P4=EApKlQwATjqsOibgA87H69FzpEU%2fCFOQ%2fARRv9J82CUe6a4CtVAQBcDUk1mCV4JK3Ghg62UWi0fX2MS0F7Wq%2fA%3d%3d http://dl.delivery.mp.microsoft.com/filestreamingservice/files/83533985-0915-4337-b849-532913e9d544 I am unsure of these links being timed or session-based, so if they do expire, here is how to get them again: - Visit: https://store.rg-adguard.net/ (This is a third-party site, disable ads and javascript before visiting to be sure.) - Select URL (link) from the drop down. - Enter: https://www.microsoft.com/store/productId/9NBLGGH4RV3K This will pull real/valid links from Microsofts store. You can verify the links before downloading them to trust their locations as needed. The appx's are downloaded from Microsofts servers directly, so they are safe. Doing this will get you the needed requirement to get this installed and working.

claunia commented

@camp-007 commented on GitHub (Apr 17, 2020):

@atom0s Thanks for the info. The store.rg-adguard.net seemed a bit shady to me, but I can confirm that process worked for me. To restate your solution and my path to resolution:

Problem:

choco install microsoft-windows-terminal would fail with errors about missing packages for
Microsoft.VCLibs.140.00.UWPDesktop or Microsoft.VCLibs.140.00

Get-AppxPackage | where name -like "Microsoft.VC*" | select Name, Version, PackageFamilyName would show these packages but not with the latest/required versions

Solution:

Visit the somewhat shady feeling site: https://store.rg-adguard.net/ to download appx packages directly out of the microsoft store. The links generated are from microsoft.com domains.
Search by PackageFamilyName for Microsoft.VCLibs.140.00.UWPDesktop_8wekyb3d8bbwe
- For me, the generated link for x64 was: Microsoft.VCLibs.140.00.UWPDesktop_14.0.27810.0_x64__8wekyb3d8bbwe.appx
Search by PackageFamilyName for Microsoft.VCLibs.140.00_8wekyb3d8bbwe
- For me the generated link for x64 was: Microsoft.VCLibs.140.00_14.0.27810.0_x64__8wekyb3d8bbwe.appx
run Add-AppxPackage -Path .\Microsoft.VCLibs.140.00.UWPDesktop_14.0.27810.0_x64__8wekyb3d8bbwe.appx
run Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_14.0.27810.0_x64__8wekyb3d8bbwe.appx
run choco install microsoft-windows-terminal which now succeeds

@camp-007 commented on GitHub (Apr 17, 2020): @atom0s Thanks for the info. The store.rg-adguard.net seemed a bit shady to me, but I can confirm that process worked for me. To restate your solution and my path to resolution: ### Problem: `choco install microsoft-windows-terminal` would fail with errors about missing packages for `Microsoft.VCLibs.140.00.UWPDesktop` or `Microsoft.VCLibs.140.00` `Get-AppxPackage | where name -like "Microsoft.VC*" | select Name, Version, PackageFamilyName` would show these packages but not with the latest/required versions ### Solution: - Visit the somewhat shady feeling site: https://store.rg-adguard.net/ to download appx packages directly out of the microsoft store. The links generated are from microsoft.com domains. - Search by *PackageFamilyName* for `Microsoft.VCLibs.140.00.UWPDesktop_8wekyb3d8bbwe` - For me, the generated link for x64 was: [Microsoft.VCLibs.140.00.UWPDesktop_14.0.27810.0_x64__8wekyb3d8bbwe.appx](http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/0e19f025-0004-48c2-b699-ee1a275389b7?P1=1587145145&P2=402&P3=2&P4=ORyZzbFyStMFDD0IQAFawhFUtROdd7Nd8gSjEIl4IzxxLguuimPdAdJ3TC2%2b1Cm0FanbucNGv0xQbbSOkMHFYg%3d%3d) - Search by *PackageFamilyName* for `Microsoft.VCLibs.140.00_8wekyb3d8bbwe` - For me the generated link for x64 was: [Microsoft.VCLibs.140.00_14.0.27810.0_x64__8wekyb3d8bbwe.appx](http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/628f920b-6ee5-4f64-9988-8e840bc0aa5d?P1=1587142291&P2=402&P3=2&P4=bWDil9PMYqTcYdfQqBqu4PkD6f5aHmWvTuTQZxzdw%2bykcWAU4tAzpqfOSFWbSnKPfNVUUx33xE6MMrMXDt6tDw%3d%3d) - run `Add-AppxPackage -Path .\Microsoft.VCLibs.140.00.UWPDesktop_14.0.27810.0_x64__8wekyb3d8bbwe.appx` - run `Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_14.0.27810.0_x64__8wekyb3d8bbwe.appx` - run `choco install microsoft-windows-terminal` which now succeeds

claunia commented

@damienleroy commented on GitHub (Apr 20, 2020):

Working well on my side too.
Thanks @atom0s ! (and @camp-007 for the clearest explanation :) )

@damienleroy commented on GitHub (Apr 20, 2020): Working well on my side too. Thanks @atom0s ! (and @camp-007 for the clearest explanation :) )

claunia commented

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

the msixbundle would then work too if you want to avoid choco

@tebeco commented on GitHub (Apr 20, 2020): the `msixbundle` would then work too if you want to avoid `choco`

claunia commented

@zhangnew commented on GitHub (Apr 20, 2020):

I installed Microsoft.VCLibs.140.00.UWPDesktop_8wekyb3d8bbwe and Microsoft.VCLibs.140.00_8wekyb3d8bbwe by this way (https://github.com/microsoft/terminal/issues/3097#issuecomment-615373769),

Then download the Microsoft.WindowsTerminal_0.10.781.0_8wekyb3d8bbwe.msixbundle from releases page, and installed the app.

But can't open it, when click the start button, there is nothing, after a few miutes, show this error:

due to time out, this operation is return in English. (my pc is without network access)

@zhangnew commented on GitHub (Apr 20, 2020): I installed `Microsoft.VCLibs.140.00.UWPDesktop_8wekyb3d8bbwe` and `Microsoft.VCLibs.140.00_8wekyb3d8bbwe` by this way (https://github.com/microsoft/terminal/issues/3097#issuecomment-615373769), Then download the `Microsoft.WindowsTerminal_0.10.781.0_8wekyb3d8bbwe.msixbundle` from releases page, and installed the app. But can't open it, when click the `start` button, there is nothing, after a few miutes, show this error: ![image](https://user-images.githubusercontent.com/9146834/79734241-f6c11180-8328-11ea-9a4b-067490456ead.png) `due to time out, this operation is return` in English. (my pc is without network access)

claunia commented

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

@atom0s Your solution actually worked for me! I've attempted every other workaround posted by the devs and others here for months, and nothing has ever worked.

This seems like a byzantine process to through to install a terminal console. Not sure why Terminal so strictly require the bleeding edge release of the C++ runtime each update. Even downloading the latest release from the MS website doesn't work for me.

Only this goofy third-party search engine giving downloads from the Store seems to work.

@awarre commented on GitHub (Apr 23, 2020): @atom0s Your solution actually worked for me! I've attempted every other workaround posted by the devs and others here for months, and nothing has ever worked. This seems like a byzantine process to through to install a terminal console. Not sure why Terminal so strictly require the bleeding edge release of the C++ runtime each update. Even downloading the latest release from the MS website doesn't work for me. Only this goofy third-party search engine giving downloads from the Store seems to work.

claunia commented

@thomas-ashcraft commented on GitHub (Apr 24, 2020):

@atom0s thank you for solution. It works on some systems. x86 installs on every machine without any problmes. But my primary notebook, are not able to install x64 version of that package. Says:

App installation failed with error message: Ошибка 0x80073D02: не удалось выполнить установку, так как требуется закрыть следующие приложения: Microsoft.DesktopAppInstaller_1.0.32912.0_x64__8wekyb3d8bbwe. (0x80073d02)

Means: "Error 0x80073D02: cannot perform an installation, because you need to close those applications". The trick is: installation of .appx file (as I understand) performed by DesktopAppInstaller. So it literally asks to close itself, because it cannot perform its own functions, because of itself. Wut?

P.S.
Guys/girls/persons/kind-folks from Microsoft... Im risking to trigger your holy rage by that question, but I feel like I must to ask. Even if no one will answer, it will seed the idea. Can't you please just follow the RPM system so we all can to sigh with a relief at last? I know that in *nix world it is not the newest and best. Yet for Windows it will be like divine revelation and next level ascension.

@thomas-ashcraft commented on GitHub (Apr 24, 2020): @atom0s thank you for solution. It works on some systems. x86 installs on every machine without any problmes. But my primary notebook, are not able to install x64 version of that package. Says: > App installation failed with error message: Ошибка 0x80073D02: не удалось выполнить установку, так как требуется закрыть следующие приложения: Microsoft.DesktopAppInstaller_1.0.32912.0_x64__8wekyb3d8bbwe. (0x80073d02) Means: "_Error 0x80073D02: cannot perform an installation, because you need to close those applications_". The trick is: installation of .appx file (as I understand) performed by DesktopAppInstaller. So it literally asks to close itself, because it cannot perform its own functions, because of itself. Wut? P.S. Guys/girls/persons/kind-folks from Microsoft... Im risking to trigger your holy rage by that question, but I feel like I must to ask. Even if no one will answer, it will seed the idea. Can't you please just follow the RPM system so we all can to sigh with a relief at last? I know that in *nix world it is not the newest and best. Yet for Windows it will be like divine revelation and next level ascension.

claunia commented

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

For me, I had to run the appx files directly, not from the command line. As for your issue in general, you could try killing everything running on your system including Explorer, and directly run the appx as a new task through Task Manager while everything is shut off and see if it bypasses that kind of issue of being in-use.

@atom0s commented on GitHub (Apr 24, 2020): For me, I had to run the appx files directly, not from the command line. As for your issue in general, you could try killing everything running on your system including Explorer, and directly run the appx as a new task through Task Manager while everything is shut off and see if it bypasses that kind of issue of being in-use.

claunia commented

@DHowett-MSFT commented on GitHub (Apr 30, 2020):

In the interest of making Terminal easily accessible in environments where the store isn’t available, we’re going to ship our dependencies inside our package for now. We’ll revisit this once we have a better story.

This issue will close when the PR that integrates our dependencies merges (in a minute or so.)

@DHowett-MSFT commented on GitHub (Apr 30, 2020): In the interest of making Terminal easily accessible in environments where the store isn’t available, we’re going to ship our dependencies inside our package for now. We’ll revisit this once we have a better story. This issue will close when the PR that integrates our dependencies merges (in a minute or so.)

claunia commented

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

@DHowett-MSFT It appears that ever since PR #5256 , The appx-Release bundle is no longer generated. Shipping the deps only helps when a release is published but what if we want to roll a custom build? We should be able to grab the appx. Visual Studio still shouldn't be required.

@WSLUser commented on GitHub (May 4, 2020): @DHowett-MSFT It appears that ever since PR #5256 , The appx-Release bundle is no longer generated. Shipping the deps only helps when a release is published but what if we want to roll a custom build? We should be able to grab the appx. Visual Studio still shouldn't be required.

claunia commented

2026-01-30 23:44:00 +00:00

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

@WSLUser If you are sharp enough to roll a custom build, you're capable enough of finding and installing its dependencies. Also, we haven't changed how the CI pipelines publish app packages, and the build changes in the msbuild projects only impact builds with a specific flag turned on.

@DHowett-MSFT commented on GitHub (May 4, 2020): @WSLUser If you are sharp enough to roll a custom build, you're capable enough of finding and installing its dependencies. Also, we haven't changed how the CI pipelines publish app packages, and the build changes in the msbuild projects only impact builds with a specific flag turned on.

claunia commented

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

5256 was made because we spent too much time rebuilding unchanged code for flavors that we've never picked up any regressions in. Our CI is not a contract. You are not supposed to rely on the availability of any bundles from our CI. It's not a contract.

@DHowett-MSFT commented on GitHub (May 4, 2020): 5256 was made because we spent too much time rebuilding unchanged code for flavors that we've never picked up any regressions in. Our CI is not a contract. You are not supposed to rely on the availability of any bundles from our CI. It's not a contract.

claunia commented

2026-01-30 23:44:00 +00:00

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

Yes, and I did notice #5679 did publish an artifact, except the x64 build failed due to circular graph, so anybody not using x64 could grab it. That graph issue usually just requires a rebuild. Obviously no point to rebuild for that PR as it's for v1 but I was hoping to update my offline machine with the latest appx bundle now that the deps are shipped as part of it.

@WSLUser commented on GitHub (May 4, 2020): Yes, and I did notice #5679 did publish an artifact, except the x64 build failed due to circular graph, so anybody not using x64 could grab it. That graph issue usually just requires a rebuild. Obviously no point to rebuild for that PR as it's for v1 but I was hoping to update my offline machine with the latest appx bundle now that the deps are shipped as part of it.

claunia commented

2026-01-30 23:44:00 +00:00

@ghost commented on GitHub (May 5, 2020):

:tada:This issue was addressed in #5661, which has now been successfully released as Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1).🎉

Handy links:

@ghost commented on GitHub (May 5, 2020): :tada:This issue was addressed in #5661, which has now been successfully released as `Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1)`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.11.1251.0 (1.0rc1)) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

claunia commented

@m-wilczynski commented on GitHub (May 12, 2020):

Seems to work now! <3

A minor inconvenience is that it will install successfully, but you need to wait few minutes (or launch Microsoft Store, can't be sure) for it to start working properly. When you click on the icon in Start Menu it will behave as if installation was still in progress (even progressbar is still present).

@m-wilczynski commented on GitHub (May 12, 2020): Seems to work now! <3 A minor inconvenience is that it will install successfully, but you need to wait few minutes (or launch Microsoft Store, can't be sure) for it to start working properly. When you click on the icon in Start Menu it will behave as if installation was still in progress (even progressbar is still present).

claunia commented

@rklec commented on GitHub (Jun 21, 2022):

Does this issue happen again? See https://github.com/microsoft/terminal/issues/13345

@rklec commented on GitHub (Jun 21, 2022): Does this issue happen again? See https://github.com/microsoft/terminal/issues/13345

claunia commented

@zadjii-msft commented on GitHub (Jun 21, 2022):

Leaving here for future folks. These are from the Release Notes:

Why are there so many packages? How do I choose?

This version of Windows Terminal is distributed in two bundles, one of which works on Windows 10-11 and the other of
which only works on Windows 11. The Windows 11 version is much smaller because we no longer need to work around a
platform issue related to our dependencies.

If you intend on using Terminal as an unpackaged application--that is, extracting the msix file--we recommend that
you use the Win10 bundle. You will need the Visual C++ runtime redistributable.

In addition, if you install the packaged version on either Windows 10 or Windows 11, it now depends on the Visual C++ Universal Runtime Package.

Despite these distributions having different version numbers, they are built from the same code and there is no
functional difference between them.

If you install the Windows 10 verison on Windows 11, it will probably automatically upgrade itself to the Windows 11
version. It turns out that it is impossible to have two bundles with the same version number, so it has to be this
way.

As with prior releases, you need to install Microsoft.VCLibs.UWPDesktop.140.00 or make sure it is installed prior to installing Terminal. If you are using Terminal unpackaged, you will need to make sure you have the systemwide "Microsoft Visual C++ Redistributable" installed, and choose the Win10 version of our msixbundle. Yeah, it's strange!

@zadjii-msft commented on GitHub (Jun 21, 2022): Leaving here for future folks. These are from the Release Notes: > ## Why are there so many packages? How do I choose? > This version of Windows Terminal is distributed in two bundles, one of which works on Windows 10-11 and the other of > which only works on Windows 11. The Windows 11 version is much smaller because we no longer need to work around a > platform issue related to our dependencies. > > If you intend on using Terminal as an unpackaged application--that is, extracting the `msix` file--we recommend that > you use the `Win10` bundle. You will need the [Visual C++ runtime redistributable](https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist). > > In addition, if you install the _packaged_ version on either Windows 10 or Windows 11, it now depends on [the Visual C++ Universal Runtime Package](https://docs.microsoft.com/en-us/troubleshoot/developer/visualstudio/cpp/libraries/c-runtime-packages-desktop-bridge?msclkid=3e1dd82aac8b11ec8f9dbd86d5979ca8#how-to-install-and-update-desktop-framework-packages). > > Despite these distributions having different version numbers, they are built from the same code and there is no > functional difference between them. > > If you install the Windows 10 verison on Windows 11, it will probably automatically upgrade itself to the Windows 11 > version. It turns out that it is impossible to have two bundles with _the same version number_, so it has to be this > way. > As with prior releases, you need to install `Microsoft.VCLibs.UWPDesktop.140.00` or make sure it is installed prior to installing Terminal. If you are using Terminal _unpackaged_, you will need to make sure you have the systemwide "Microsoft Visual C++ Redistributable" installed, and choose the _Win10_ version of our msixbundle. Yeah, it's strange!

claunia commented