-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It is hard to find Microsoft.VCLibs.140.00.UWPDesktop #3097
Comments
Build this App on your own and make an 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. |
@bitcrazed I'm assigning this one to you per #2369 (comment) The link you provided is to the desktop application redistributable, not the |
Is there a reason why the dependencies are not in the Package? |
The dependencies are not in the package because the dependencies need to be able to be updated without us releasing an update. |
Thanks for the quick reply! |
@DHowett 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. |
I've got the same issue on my side. |
@ leroyd
@DHowett-MSFT i’m very interested to know how that msbuild check can be fixed without running the assistant twice Repro : Also does the |
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. |
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
As I mentioned in a previous comment this is what does |
@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. |
For our release builds, we're just going to integrate the UWPDesktop CRT into our package and delete the package dependencies. It's very difficult for users who do not have access to the store to get our dependency packages, and we want to be robust and deployable everywhere. Since these libraries can be redistributed, it's easiest if we simply redistribute them. Our package grows by ~550kb per architecture (compressed) because of this. I've added validation that we don't have both the libs _and_ the dependencies in the same package. Fixes #3097.
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.) |
For our release builds, we're just going to integrate the UWPDesktop CRT into our package and delete the package dependencies. It's very difficult for users who do not have access to the store to get our dependency packages, and we want to be robust and deployable everywhere. Since these libraries can be redistributed, it's easiest if we simply redistribute them. Our package grows by ~550kb per architecture (compressed) because of this. I've added validation that we don't have both the libs _and_ the dependencies in the same package. Fixes #3097. ## Validation The script does it!
@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 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. |
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. |
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. |
🎉This issue was addressed in #5661, which has now been successfully released as Handy links: |
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). |
Does this issue happen again? See #13345 |
Leaving here for future folks. These are from the Release Notes:
|
yeap this still works just fine :) |
In case someone wants to install via official URL + chocolatey, please use the following (tested on Windows Server 2022):
|
The issue PowerShell/PowerShell#13138 stays, however, on Windows 10... 🤷 $ Add-AppxPackage -Path $tempUwpASPX
Add-AppxPackage: The 'Add-AppxPackage' command was found in the module 'Appx', but the module could not be loaded due to the following error: [Operation is not supported on this platform. (0x80131539)]
For more information, run 'Import-Module Appx'.
$ Import-Module Appx
Import-Module: Operation is not supported on this platform. (0x80131539) |
Ah okay the workaround to import it was possible, but well (file was already downloaded before via
Log shows:
|
Even a fresh installation seems to fail with:
Maybe a different chocolately problem. Anyway, this is a mes, I've switched to https://tabby.sh/ for now... |
Hi everyone,
After installing the suggested VClibs at - #2369
the installer still shows:
(They said to open a new issue report)
Best Regards
The text was updated successfully, but these errors were encountered: