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

shalev123d commented 4 years ago

Hi everyone, After installing the suggested VClibs at - https://github.com/microsoft/terminal/issues/2369 the installer still shows: (They said to open a new issue report)

Best Regards

EmTschi commented 4 years ago

Build this App on your own and make an appx. It creates also the dependencies (Microsoft.VCLibs.x64.14.00.appx, Microsoft.VCLibs.x64.14.00.Desktop.appx)

Extract the downloaded msixbundle File and copy the created dependencies (Microsoft.VCLibs.x64.14.00.appx, Microsoft.VCLibs.x64.14.00.Desktop.appx) in the same Folder as the CascadiaPackage_xxx_x64.msix is and install it.

On a new release you can reuse this dependencies. Only extract und copy the files.

DHowett-MSFT commented 4 years ago

@bitcrazed I'm assigning this one to you per https://github.com/microsoft/terminal/issues/2369#issuecomment-535763987

The link you provided is to the desktop application redistributable, not the UWPDesktop redistributable.

EmTschi commented 4 years ago

Is there a reason why the dependencies are not in the Package? The app installer needs always the dependencies, also if the dependencies are already installed...

DHowett-MSFT commented 4 years ago

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

EmTschi commented 4 years ago

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

tebeco commented 4 years ago

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.

damienleroy commented 4 years ago

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 ?

tebeco commented 4 years ago

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

bitcrazed commented 4 years ago

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.

tebeco commented 4 years ago

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

bitcrazed commented 4 years ago

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

tebeco commented 4 years ago

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

gbargsley commented 4 years ago

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.

tebeco commented 4 years ago

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.

WSLUser commented 4 years ago

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 4 years ago

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

4integration commented 4 years ago

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

tebeco commented 4 years ago

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

deskoh commented 4 years ago

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

tebeco commented 4 years ago

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

jheiselman commented 4 years ago

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_x648wekyb3d8bbwe 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_x648wekyb3d8bbwe 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 4 years ago

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

thomas-ashcraft commented 4 years ago

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

tebeco commented 4 years ago

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

thomas-ashcraft commented 4 years ago

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!

DHowett-MSFT commented 4 years ago

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

tebeco commented 4 years ago

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

DHowett-MSFT commented 4 years ago

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

tebeco commented 4 years ago

(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

DHowett-MSFT commented 4 years ago

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.

tebeco commented 4 years ago

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:

kevinbowman commented 4 years ago

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.

bitcrazed commented 4 years ago

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.

rogusdev commented 4 years ago

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

atom0s commented 4 years ago

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.

camp-007 commented 4 years ago

@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

damienleroy commented 4 years ago

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

tebeco commented 4 years ago

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

zhangnew commented 4 years ago

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)

awarre commented 4 years ago

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

thomas-ashcraft commented 4 years ago

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

atom0s commented 4 years ago

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.

DHowett-MSFT commented 4 years ago

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

WSLUser commented 4 years ago

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

DHowett-MSFT commented 4 years ago

@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 4 years ago

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.

WSLUser commented 4 years ago

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.

ghost commented 4 years ago

: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

m-wilczynski commented 4 years ago

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

rklec commented 2 years ago

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

microsoft / terminal