-
Notifications
You must be signed in to change notification settings - Fork 53
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
Updating VisualStudio LTSC installations #139
base: master
Are you sure you want to change the base?
Conversation
I don't have any experience with the LTSC releases, but I think I understand the problem. First, some organizational matters:
Now, regarding the change itself. This: $installed = Get-VisualStudioInstance | Where-Object { $_.ChannelId -like ($channelReference.ChannelId+ "*")} may return more than one object when there are multiple VS instances installed (the user can have different products installed, such as Build Tools and Test Agent, or multiple installations of one product). Deeper in the extension, the I would also like to fully understand your scenario. Can you provide specific steps to reproduce the issue (let's say starting with a clean system with only Chocolatey installed)? |
My team is deploying chocolatey packages of Visual Studio on a private repository, each one with the version we want, for example, Visual Studio 2022 Enterprise version 17.2.5 is one, version 17.2.7 is another (this one is LTSC) and 17.2.8 is another one (also LTSC). For that we relied on your community package, but we are passing one more parameter to the We recently moved from 17.2.5, a non-LTSC version to 17.2.7, an LTSC one, and everything went well. When then we wanted to updated it to 17.2.8 LTSC, the package failed to install.
In order to replicate this behaviour you can do the following (with only Chocolatey installed):
|
Thank you for the very detailed description, that really helps. |
I think I would like the default behavior of the packages/extension to be to assume the Current channel and only pick installed instances which refer to that channel when determining the instances to upgrade. This would be similar to how packages for VS Preview ignore VS "stable" and vice versa. Still, the user always has the ability to override the instance selection logic by passing |
Also:
Please note that the DesiredProductVersion parameter is used only for determining whether an existing VS instance should be upgraded (if installed version is equal or higher, it will not be upgraded) and for checking if the upgrade succeeded (after upgrade, the installed version should be equal to DesiredProductVersion). It does NOT influence the upgrade process in any way, i.e. the value of DesiredProductVersion has no effect on the VS version which will actually be installed. The actually installed VS version is determined only by the channel manifest used during installation. The VS Installer may obtain the channel manifest from various sources:
Incidentally, this hints at one way of creating "fixed version" choco packages for any VS version - the package could contain an embedded channel manifest file, downloaded at some point from the default/evergreen url. Such a package would probably not be publishable on chocolatey.org (due to uncertain redistribution rights for the channel manifest), but would be perfectly OK for internal use. That way, if you just want to have packages which install a specific VS version in a deterministic way, you can create them from the Current channel and avoid the complications related to switching channels. (Personally, I have an Azure DevOps pipeline, which runs daily, downloads the channel manifest from the Current channel and stores it in a Git repo. That way, I have the ability to easily go back to any VS version ever released in the Current channel, without relying on the fixed version installers published by MS.) |
This currently fails for me even on the second package (when attempting to upgrade a Current 17.2.5 to LTSC 17.2.7): the VS Installer gets updated, but then hangs - two setup.exe processes remain running, but do nothing. When invoked with However, upgrading LTSC to LTSC should probably work. Attempting to perform it via the third package fails because the extension enters the "install a new instance" code path instead of the one for upgrading. I'm becoming more and more convinced now the extension should be told (by the package) about the channel. I have an idea for fixing this, while also at the same time implementing a feature I've been postponing for a long time, namely, the ability for a package to specify default values for package parameters (which will make it easier to create packages with embedded channel manifest files and/or bootstrappers - those packages will set installChannelUri/bootstrapperPath). |
Yes, the bootstrapper installs the specific version, I forgot that. When repeating the above procedures I also got stuck in the 17.2.7 installation, I don't know why, because it worked in the past. If I change manually the channel I will use, it allows me to install it, but it worked without this.
I'll be waiting for this :) |
…values Related issue: GH-139
…values Related issue: GH-139
…cting channelId from package parameters Related issue: GH-139
…duct ids to support packages which set a custom channel Related issue: GH-139
…duct ids to support packages which set a custom channel Related issue: GH-139
…cting channelId from package parameters Related issue: GH-139
…duct ids to support packages which set a custom channel Related issue: GH-139
Implemented in extension 1.11.0 (currently in preview). I've also added example LTSC packages as well as fixed version variants (packages which always install a specific VS version) of both Current and LTSC. I don't intend to publish them to chocolatey.org at this time, because I don't have the capacity to support them, but they can serve as a template for anyone making their own. |
Here are example scripts from an "evergreen" package which installs the latest version from the LTSC 17.4 channel: ChocolateyInstall.ps1 Install-VisualStudio `
-PackageName 'visualstudio2022buildtools-ltsc17.4' `
-ApplicationName 'Microsoft Visual Studio Build Tools 2022' `
-Url 'https://download.visualstudio.microsoft.com/download/pr/0bb9a5f5-5481-4efe-92ab-cca29a90fa5e/d0806da38afe46b8476ec8f206edd304b1ca60891c2967604846d3cf761b4875/vs_BuildTools.exe' <# https://aka.ms/vs/17/release.ltsc.17.4/vs_buildtools.exe #> `
-Checksum 'D0806DA38AFE46B8476EC8F206EDD304B1CA60891C2967604846D3CF761B4875' `
-ChecksumType 'SHA256' `
-InstallerTechnology 'WillowVS2017OrLater' `
-Product 'BuildTools' `
-VisualStudioYear '2022' `
-Preview $false `
-DefaultParameterValues @{ channelId = 'VisualStudio.17.Release.LTSC.17.4' } ChocolateyUninstall.ps1 Remove-VisualStudioProduct `
-PackageName 'visualstudio2022buildtools-ltsc17.4' `
-Product 'BuildTools' `
-VisualStudioYear '2022' `
-Preview $false `
-DefaultParameterValues @{ channelId = 'VisualStudio.17.Release.LTSC.17.4' } And here are scripts from a "fixed version" package which always installs version 17.4.6 from this channel: ChocolateyInstall.ps1 Install-VisualStudio `
-PackageName 'visualstudio2022buildtools-ltsc17.4' `
-ApplicationName 'Microsoft Visual Studio Build Tools 2022' `
-Url 'https://download.visualstudio.microsoft.com/download/pr/d1ed8638-9e88-461e-92b7-4e29cc6172c3/38b09fc09ae9e590b73ae6752a0ebfd62579798969041bd341689273b842bc10/vs_BuildTools.exe' <# https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history #> `
-Checksum '38B09FC09AE9E590B73AE6752A0EBFD62579798969041BD341689273B842BC10' `
-ChecksumType 'SHA256' `
-InstallerTechnology 'WillowVS2017OrLater' `
-Product 'BuildTools' `
-VisualStudioYear '2022' `
-Preview $false `
-DefaultParameterValues @{ channelId = 'VisualStudio.17.Release.LTSC.17.4'; installChannelUri = 'https://aka.ms/vs/17/release.ltsc.17.4/176788236_-978989559/channel' } ChocolateyUninstall.ps1 (same as evergreen) Remove-VisualStudioProduct `
-PackageName 'visualstudio2022buildtools-ltsc17.4' `
-Product 'BuildTools' `
-VisualStudioYear '2022' `
-Preview $false `
-DefaultParameterValues @{ channelId = 'VisualStudio.17.Release.LTSC.17.4' } |
Some more findings from the tests:
|
When installing Visual Studio 2022 17.2.8 (LTSC) on a machine where Visual Studio 2022 17.2.7 (LTSC) was already installed, the installer exited with error, when using the
DesiredVersion
flag.The channel for LTSC has
.LTSC.<version>
appended so it would fail to obtain a more recent version of the regular channel.We need to get the installed channel, if it exists, and use it, otherwise, we would follow the path it would follow without any changes