Install-ChocolateyVsixPackage.ps1 Doesnt work with 2017 packages

[bbowman]

Please follow https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/ to find VS installs now.

[ferventcoder]

@bbowman can you provide more context? What needs to change? Is it simply an issue like #1056? That is being fixed for 0.10.4.

[bbowman]

The install dir for Visual Studio 2017 is no longer discoverable from the registry and instead you need to make a few COM calls to the setup engine to query it for installs. Thus the logic to find a valid VSIXInstaller.exe to use for the install in Install-ChocolateyVsixPackage.ps1 will need to be changed for 2017 installs.

[gep13]

@bbowman you can use the vswhere.exe to find the installation path.

[gep13]

vswhere is actually available as a Chocolatey Package: https://chocolatey.org/packages/vswhere

[bbowman]

@ferventcoder @gep13 Thanks guys! I coded up a small workaround for our package at microsoft/WinObjC#2233 ... I still think this is a good candidate to get into 0.10.5

I also saw that there are a few more error states for blocked process that makes an unattended / silent install challenging. I'd love to see some ideas on how to handle that.

[ferventcoder]

I also saw that there are a few more error states for blocked process that makes an unattended / silent install challenging. I'd love to see some ideas on how to handle that.

#725?

[StefanScherer]

Finally found this issue after trying to spin up a new Vagrant box with

iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
choco install -y visualstudio2017enterprise
choco install -y visualstudio-github

So installing and running vswhere shows me

PS C:\Windows\system32> vswhere
Visual Studio Locator, version 1.0.58
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: 497100bf
installDate: 3/17/2017
installationName: VisualStudio/15.0.0+26228.9
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise
installationVersion: 15.0.26228.9
displayName: Visual Studio Enterprise 2017
description: Microsoft DevOps solution for productivity and coordination across teams of any size
enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
channelId: VisualStudio.15.Release
channelPath: C:\Users\vagrant\AppData\Local\Microsoft\VisualStudio\Packages\_Channels\4CB340F5\catalog.json
channelUri: https://aka.ms/vs/15/release/channel

The registry has these entries

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\Registration]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\Registration\08860]
"EditionID"=dword:00000004
"ProductID"="00369-60000-00001-AA402"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7]
"15.0"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\"

The VsixInstaller.exe can be found in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE

[bbowman]

@ferventcoder #725 is different. The scenario in this case is that the user has visual studio running when trying to install a 2017 VSIX. When not running the installer in quiet mode, the GUI shows that the running instance of VS is blocking the install and the installer waits until the user closes this otherwise unrelated process. The unattended installer just hangs for ~5 minutes and then returns 2004? (I'm on mobile so I forget the exact error code and can't easily look it up) to indicate the install is blocked. In my package I error out here and show a message about closing instances of VS and to try again.

Ideally I'd like to be able to still succeed (with the users help) in this case. Maybe the chocolatey script needs to list known VS processes that are running on the machine?

Perhaps @gep13 or others familiar with vswhere know of a way to query for running instances or something to be more useful than a 5 minute timeout.

Thoughts?

[ferventcoder]

The scenario in this case is that the user has visual studio running when trying to install a 2017 VSIX. When not running the installer in quiet mode, the GUI shows that the running instance of VS is blocking the install and the installer waits until the user closes this otherwise unrelated process. The unattended installer just hangs for ~5 minutes and then returns 2004? (I'm on mobile so I forget the exact error code and can't easily look it up) to indicate the install is blocked. In my package I error out here and show a message about closing instances of VS and to try again.

@bbowman is this new? I always thought I could install VSIXs with Visual Studio running before. If this is new, wouldn't you agree that this is kind of suboptimal and it (VSIX installer) should allow the install to move forward but just not load it into the currently running Visual Studio?

[ferventcoder]

Taking Chocolatey out of the equation for a moment and just talking about silent installation.

What options are available here?

[bbowman]

@ferventcoder Yes this is new. Visual Studio changed their extension model for 2017 (@heaths can probably shed some light here or knows who can?). I would agree that the silent installation option doesn't seem as robust in the model. I also know that VS2017 update 1 is coming soon so maybe there are improvements we can expect there?

In terms of options for silent installation in general:

1. we could try to detect and kill any running instances of visual studio but that is a non starter as a user might be working on something critical

2. we could detect and fail the install before we call out to the installer. This is also kind of a non starter because it fails the install in a scenario that could be successful.

3. we could detect this scenario and launch the installer not silently (only when this scenario is detected). This would allow to be silent in hopefully most cases but present the user with the most information in cases we can't be? This isn't ideal especially if the user isn't running in a mode where this UI would be readily visible (I'm thinking SSH'ed in or something).

Seems like we have a few not great options. Ideally we can get some input from vs folks to make a better choice?

[ferventcoder]

Another option here:

4. Fix the limitation and allow for the install to happen silently even if there are running instances of Visual Studio, then load the new extensions at the next restart of Visual Studio. (the same as the old behavior - the current way it works in 2017 is a regression aka a bug).

In a pinch, option 3 could be used. However even that option still needs a timeout as otherwise it is not a robust enterprise type of deployment without some predictability of silent deployment (blocking on a GUI thread forever is a non-starter).

Option 2 is probably the next option - it would need to exit with a different code so it's known why it failed.

Here's the best option - support all three of your options by adding additional switches to the VSIX installer to allow for these options to be set by the user performing the installs. Then set a sensible default, which might be 2 or 3.

[ferventcoder]

Where does the VS team congregate these days? Where can we file issues?

[gep13]

This is probably as good a place to start as any...

https://gitter.im/Microsoft/extendvs

Lots of VS Development Team people's in there.

[bbowman]

Also https://github.com/Microsoft/vsixbootstrapper seems like it might be useful for this discussion.

[jberezanski]

chocolatey-visualstudio.extension now includes the Install-VisualStudioVsixExtension helper, which is API-compatible with Install-ChocolateyVsixPackage and adds these features:

• supports VS 2017 (in addition to all previous VS versions)
• allows passing custom parameters to vsixinstaller.exe by means of --package-parameters (this allows, for example, installing an extension into specific VS instances only)

A slight semantic change from Install-ChocolateyVsixPackage is that the VisualStudioVersion parameter is declared (for API compatibility), but ignored. It never worked properly as advertised in the original helper (it influenced the choice of the vsixinstaller.exe version to use, but did not explicitly restrict the installation to specific VS versions). Also, I believe that choice should be left at the discretion of the user (possible now via --package-parameters), not hardcoded in the the package by the maintainer.

The extension is currently in prerelease status (version 1.6.0-rc7), pending some more testing. It can be evaluated using the latest prerelease of the stylecop-vsix package (version 5.0.6419.0-rc2). Example command lines:

# install the vsix into all instances of all VS versions and products (supported by the vsix) installed on the machine
cinst -y stylecop-vsix --pre

# install the vsix into VS 2013 Professional only
cinst -y stylecop-vsix --pre --params "--skuName Pro --skuVersion 12.0"

# install the vsix into all instances of VS 2017 Community installed on the machine
cinst -y stylecop-vsix --pre --params "--skuName Community --skuVersion 15.0"

# install the vsix into the one specific instance of VS 2017 Community
cinst -y stylecop-vsix --pre --params "--appIdInstallPath C:\Program Files (x86)\Microsoft Visual Studio\2017\Community --appIdName VS --skuName Community --skuVersion 15.0"

# install the vsix into the one specific instance of a VS 2017 product
# the instance id can be obtained via vswhere.exe or Get-VSSetupInstance (from the VSSetup.Powershell module)
cinst -y stylecop-vsix --pre --params "--instanceIds e6d6df86"

If nothing bad comes up, I'll release the packages as official versions in a couple of days.

[jberezanski]

Both packages are now available as official versions: chocolatey-visualstudio.extension, stylecop-vsix.

[theperm]

I am unable to install any extensions from the VS Gallery. It looks like there is still an issue. Can you try the following?

Install-VisualStudioVsixExtension -PackageName "WixToolsetExtension" -VsixUrl https://marketplace.visualstudio.com/_apis/public/gallery/publishers/RobMensching/vsextensions/WixToolsetVisualStudio2017Extension/0.9.21.62588/vspackage
WARNING: Missing package checksums are not allowed (by default for HTTP/FTP,
HTTPS when feature 'allowEmptyChecksumsSecure' is disabled) for
safety and security reasons. Although we strongly advise against it,
if you need this functionality, please set the feature
'allowEmptyChecksums' ('choco feature enable -n
allowEmptyChecksums')
or pass in the option '--allow-empty-checksums'. You can also pass
checksums at runtime (recommended). See choco install -? for details.
This package downloads over HTTPS but does not yet have package checksums to verify the package. We recommend asking the maintainer to add checksums to
this package. In the meantime if you need this package to work correctly, please enable the feature allowEmptyChecksumsSecure, provide the runtime switch
'--allow-empty-checksums-secure', or pass in checksums at runtime (recommended - see 'choco install -?' / 'choco upgrade -?' for details).
At C:\ProgramData\chocolatey\helpers\functions\Get-CheckSumValid.ps1:167 char:7

•   throw "This package downloads over HTTPS but does not yet have  ...
  

•   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : OperationStopped: (This package do...' for details).:String) [], RuntimeException
  • FullyQualifiedErrorId : This package downloads over HTTPS but does not yet have package checksums to verify the package. We recommend asking the mai
    ntainer to add checksums to this package. In the meantime if you need this package to work correctly, please enable the feature allowEmptyChecksumsSec
    ure, provide the runtime switch '--allow-empty-checksums-secure', or pass in checksums at runtime (recommended - see 'choco install -?' / 'choco upgra
    de -?' for details).

[jberezanski]

@theperm can you create an issue here?

[jberezanski]

@theperm can you create an issue here?

Scratch that. I'm guessing you are running Install-VisualStudioVsixExtension directly from a PowerShell prompt (after manually importing the chocolatey-visualstudio.psm1 and chocolateyInstaller.psm1 modules). The error you are running into is expected in this case, because the helper functions expect certain environment variables to be set (choco.exe does it before invoking the PowerShell scripts).

Try building an actual package for that vsix and installing it with choco.

[theperm]

I think I tried it from a boxstarter package as that's where I want to use it. Is that supported?

…

On Tue, 15 May 2018, 21:19 Jakub Bereżański, ***@***.***> wrote: @theperm <https://github.com/theperm> can you create an issue here? Scratch that. I'm guessing you are running Install-VisualStudioVsixExtension directly from a PowerShell prompt (after manually importing the chocolatey-visualstudio.psm1 and chocolateyInstaller.psm1 modules). The error you are running into is expected in this case, because the helper functions expect certain environment variables to be set (choco.exe does it before invoking the PowerShell scripts). Try building an actual package for that vsix and installing it with choco. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1201 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyHqWfw47igUHCaZQQtv3xIZkMWC-m9ks5tyzhIgaJpZM4Mb_p-> .

[jberezanski]

As I have no experience with Boxstarter, I don't know how Boxstarter packages and their execution environment differ from Chocolatey packages. chocolatey-visualstudio.extension is designed and tested only for usage inside Chocolatey.

I suggest you put Boxstarter aside for the moment, build and test your package in plain Chocolatey, and, once you confirm it works, try to install it with Boxstarter (and seek assistance from Boxstarter authors if something fails at that point).