Similar Problems:

• chocolatey-archive/chocolatey#579
• https://github.com/chocolatey/shimgen/issues/2
• https://github.com/chocolatey/shimgen/issues/4
  My Problem is i don't want the exe generated from shimgen to show their logo and description, but instead use my own logo and desciption.
  

┆Issue is synchronized with this Gitlab issue by Unito

What You Are Seeing?

Error when installing Chocolatey.

Querying latest package from https://proget.internal.repo/nuget/chocolatey/Packages()?$filter=(Id%20eq%20%27chocolatey%27)%20and%20IsLatestVersion
Downloading  to c:\temp\chocolatey.0.10.15.nupkg
No file exists at c:\temp\chocolatey.0.10.15.nupkg
At line:7 char:9
+         Invoke-Command -ScriptBlock { & C:\temp\Chocolatey.ps1} -Sess ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (No file exists ...y.0.10.15.nupkg:String) [], RuntimeException
    + FullyQualifiedErrorId : No file exists at c:\temp\chocolatey.0.10.15.nupkg
 
A parameter cannot be found that matches parameter name 'DestinationPath'.
The term 'C:\Users\<userName>\AppData\Local\Temp\chocolatey\chocInstall\tools\chocolateyInstall.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

What is Expected?

Chocolatey is installed via the Script.

How Did You Get This To Happen? (Steps to Reproduce)

Was using the Offline Install script with the native Expand-Archive to setup some nodes and we had the Pscx module installed on some nodes, which caused the error above.
It looks like the Public Script may also have this bug.

Believe this could be fixed by using the full path to Expand-Archive Microsoft.PowerShell.Archive\Expand-Archive

Original Issue

This issue was originally reported by joshcorr on this internal issue

┆Issue is synchronized with this GitLab issue by Unito

The highlighted link points to https://github.com/chocolatey/package-verifier/wiki, while it should instead point to https://docs.chocolatey.org/en-us/community-repository/moderation/package-verifier

┆Issue is synchronized with this GitLab issue by Unito

use this command to see what i mean:
choco install sysinternals

It takes "Forever"!

If you Shim 1 exe, no big deal.
When you Shim 123 exes from sysinternals, oh my....

┆Issue is synchronized with this Gitlab issue by Unito

Following the install guide, latest https://chocolatey.org/install.ps1 seems to incorrectly detect Choco already installed in an environment where Choco is not installed:

PowerShell:

PS C:\Users\xyz> choco
choco : The term 'choco' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ choco
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (choco:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

PS C:\Users\xyz> Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
WARNING: An existing Chocolatey installation was detected. Installation will not continue.
For security reasons, this script will not overwrite existing installations.

Please use choco upgrade chocolatey to handle upgrades of Chocolatey itself.

This is on Win 10 Enterprise, 19041.685

When shimgen is invoked from the command line with a relative output, as in calling C:\ProgramData\chocolatey\tools\shimgen.exe -o="git.exe" --path="/full/path/to/git.exe" from C:\bin, shimgen places the resulting git.exe shim in the C:\ProgramData\chocolatey\tools\ folder, not the C:\bin folder.

┆Issue is synchronized with this Gitlab issue by Unito

I've tried this, but no luck. I have a jar and a batch file for running that jar and can't get either to appear on the path in my chocolatey package.

I hoped shimgen might help, can it?

┆Issue is synchronized with this Gitlab issue by Unito

hi, we are having issues with this command:

  - task: CmdLine@2
    displayName: Install ssis-vs2019 (18mins)
    inputs:
      script: 'choco install -Y ssis-vs2019 --no-progress'

De build process gives us this error:

This is the full log:

2021-02-19T07:15:54.2589434Z ##[section]Starting: Install ssis-vs2019 (18mins)
2021-02-19T07:15:54.2849177Z ==============================================================================
2021-02-19T07:15:54.2849525Z Task         : Command line
2021-02-19T07:15:54.2849839Z Description  : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
2021-02-19T07:15:54.2851125Z Version      : 2.182.0
2021-02-19T07:15:54.2851363Z Author       : Microsoft Corporation
2021-02-19T07:15:54.2851711Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
2021-02-19T07:15:54.2852081Z ==============================================================================
2021-02-19T07:15:55.6820191Z Generating script.
2021-02-19T07:15:55.7089820Z Script contents:
2021-02-19T07:15:55.7103682Z choco install -Y ssis-vs2019 --no-progress
2021-02-19T07:15:55.7690551Z ========================== Starting Command Output ===========================
2021-02-19T07:15:55.8237308Z ##[command]"C:\windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\b3d08b75-6734-4155-bab0-96a7a43a6c60.cmd""
2021-02-19T07:15:57.2645198Z Chocolatey v0.10.15
2021-02-19T07:16:14.7671139Z Installing the following packages:
2021-02-19T07:16:14.7680629Z ssis-vs2019
2021-02-19T07:16:14.7763834Z By installing you accept licenses for the packages.
2021-02-19T07:16:19.3868002Z 
2021-02-19T07:16:19.3868965Z DotNet4.6 v4.6.00081.20150925 [Approved]
2021-02-19T07:16:19.4019181Z dotnet4.6 package files install completed. Performing other installation steps.
2021-02-19T07:16:21.1489685Z Microsoft .NET Framework 4.6 or later is already installed
2021-02-19T07:16:22.2347952Z  The install of dotnet4.6 was successful.
2021-02-19T07:16:22.2355158Z   Software install location not explicitly set, could be in package or
2021-02-19T07:16:22.2355626Z   default install location if installer.
2021-02-19T07:16:22.6362376Z 
2021-02-19T07:16:22.6363417Z DotNet4.6-TargetPack v4.6.00081.20150925 [Approved] - Possibly broken
2021-02-19T07:16:22.6376037Z dotnet4.6-targetpack package files install completed. Performing other installation steps.
2021-02-19T07:16:23.7003075Z WARNING: Url has SSL/TLS available, switching to HTTPS for download
2021-02-19T07:16:23.8558272Z Downloading DotNet46-TargetPack 
2021-02-19T07:16:23.8611070Z   from 'https://download.microsoft.com/download/8/2/F/82FF2034-83E6-4F93-900D-F88C7AD9F3EE/NDP46-TargetingPack-KB3045566.exe'
2021-02-19T07:16:24.4435549Z 
2021-02-19T07:16:24.4449880Z Download of NDP46-TargetingPack-KB3045566.exe (12.91 MB) completed.
2021-02-19T07:16:27.5146637Z Installing DotNet46-TargetPack...
2021-02-19T07:16:38.1545585Z DotNet46-TargetPack has been installed.
2021-02-19T07:16:38.2288486Z WARNING: Url has SSL/TLS available, switching to HTTPS for download
2021-02-19T07:16:38.2973885Z Downloading DotNet46-TargetPack-enu 
2021-02-19T07:16:38.2974515Z   from 'https://download.microsoft.com/download/8/2/F/82FF2034-83E6-4F93-900D-F88C7AD9F3EE/NDP46-TargetingPack-KB3045566-ENU.exe'
2021-02-19T07:16:38.5488673Z 
2021-02-19T07:16:38.5499176Z Download of NDP46-TargetingPack-KB3045566-ENU.exe (6.68 MB) completed.
2021-02-19T07:16:41.5589302Z Installing DotNet46-TargetPack-enu...
2021-02-19T07:16:50.8041096Z DotNet46-TargetPack-enu has been installed.
2021-02-19T07:16:51.2608643Z   dotnet4.6-targetpack may be able to be automatically uninstalled.
2021-02-19T07:16:51.3468175Z  The install of dotnet4.6-targetpack was successful.
2021-02-19T07:16:51.3473236Z   Software installed as 'exe', install location is likely default.
2021-02-19T07:16:51.5796078Z 
2021-02-19T07:16:51.5797157Z ssis-vs2019 v3.12 [Approved]
2021-02-19T07:16:51.5801876Z ssis-vs2019 package files install completed. Performing other installation steps.
2021-02-19T07:16:54.6812435Z Attempt to get headers for https://marketplace.visualstudio.com/_apis/public/gallery/publishers/SSIS/vsextensions/SqlServerIntegrationServicesProjects/3.12/vspackage failed.
2021-02-19T07:16:54.6814703Z   The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://marketplace.visualstudio.com/_apis/public/gallery/publishers/SSIS/vsextensions/SqlServerIntegrationServicesProjects/3.12/vspackage'. Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (429)."
2021-02-19T07:16:54.6829216Z Downloading ssis-vs2019 
2021-02-19T07:16:54.6830044Z   from 'https://marketplace.visualstudio.com/_apis/public/gallery/publishers/SSIS/vsextensions/SqlServerIntegrationServicesProjects/3.12/vspackage'
2021-02-19T07:16:56.9032864Z ERROR: The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://marketplace.visualstudio.com/_apis/public/gallery/publishers/SSIS/vsextensions/SqlServerIntegrationServicesProjects/3.12/vspackage'. Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (429)." 
2021-02-19T07:16:56.9034637Z This package is likely not broken for licensed users - see https://chocolatey.org/docs/features-private-cdn.
2021-02-19T07:16:57.2655969Z The install of ssis-vs2019 was NOT successful.
2021-02-19T07:16:57.2690658Z Error while running 'C:\ProgramData\chocolatey\lib\ssis-vs2019\tools\ChocolateyInstall.ps1'.
2021-02-19T07:16:57.2691724Z  See log for details.
2021-02-19T07:16:59.4524481Z 
2021-02-19T07:16:59.4525504Z Chocolatey installed 2/3 packages. 1 packages failed.
2021-02-19T07:16:59.4525979Z  See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
2021-02-19T07:16:59.4532875Z 
2021-02-19T07:16:59.4538584Z Failures
2021-02-19T07:16:59.4545644Z  - ssis-vs2019 (exited 404) - Error while running 'C:\ProgramData\chocolatey\lib\ssis-vs2019\tools\ChocolateyInstall.ps1'.
2021-02-19T07:16:59.4546537Z  See log for details.
2021-02-19T07:16:59.9420080Z ##[error]Cmd.exe exited with code '404'.
2021-02-19T07:16:59.9930516Z ##[section]Finishing: Install ssis-vs2019 (18mins)

Looks like MS is rejecting the connection when trying to download the package.

¿Has anyone exprecience this?

Regards.

some text

┆Issue is synchronized with this GitLab issue by Unito

The statistic for Unique packages/total packages shows just / (screenshot below).

Upon inspection in the browser console, this is likely due to the CORS policy on https://community.chocolatey.org/stats not allowing for requests originating from https://chocolatey.org or https://www.chocolatey.org (screenshot from browser console below).

┆Issue is synchronized with this GitLab issue by Unito

elgato-game-capture 3.70.51.3051 was reported to have passed verification testing even though the log shows that it failed to install.

Verifier log: https://gist.github.com/choco-bot/658bc4865e9540b35f61d77ff43c5f36

The failure to install is what I now expect to happen, as I have discovered that I forgot to upload a file to my repo (the certificated to be installed), so it failed to be included in version 3.70.51.3051 of the package, and therefore it fails unless the certificate was previously installed. I have created a new version with fix notation that includes the certificate.

The failure happened during a Start-ChocolateyProcessAsAdmin command, perhaps did it not catch it because of something relating to chocolatey/choco#1016?

┆Issue is synchronized with this Gitlab issue by Unito

Hello,

I would like to kindly submit this enhancement/feature request for consideration.

Currently Choco will install fine fine on Windows (through Tor) without issues. However installing/upgrading any package will fail as shown in the following error:

C:\Windows\system32>choco install git
Chocolatey v0.10.15
Installing the following packages:
git
By installing you accept licenses for the packages.
Error retrieving packages from source 'https://chocolatey.org/api/v2/':
 The remote server returned an error: (403) Forbidden.
git not installed. The package was not found with the source(s) listed.
 Source(s): 'https://chocolatey.org/api/v2/'
 NOTE: When you specify explicit sources, it overrides default sources.
If the package version is a prerelease and you didn't specify `--pre`,
 the package may not be found.
Please see https://chocolatey.org/docs/troubleshooting for more
 assistance.This issue is consistent with all Tor Exit nodes.Steps to reproduce: 

• install Choco on any Windows Running VM with all traffic routed through the Tor Onion network (using Whonix Gateway or pfSense for instance).
• try any package install using choco install

Expected result:

Should work

Actual result (from log):

[WARN ] - Error retrieving packages from source 'https://chocolatey.org/api/v2/':
The remote server returned an error: (403) Forbidden.

Troubleshooting steps:

Checking with browser indicates that access is protected by Cloudflare and is possible but requires hCaptcha solving when using a Tor Exit node. This is however not possible with the command line client.

This could be solved by changing a simple firewall rule or setting in Cloudflare dashboard to allow Tor Exit nodes on the API. This issue does not affect VPN users.

Choco would also be very useful and convenient to many users who want a bit more privacy by using the Tor onion network.

Thank you in advance for maybe considering this request.

AnonymousPlanet

┆Issue is synchronized with this GitLab issue by Unito

Examples:
shimgen.exe -p powershell -c "Write-Host 'Hello World'" ...

┆Issue is synchronized with this Gitlab issue by Unito

When trying to install chocolatey with this script:
Set-ExecutionPolicy Bypass -Scope Process -Force; iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
I forgot to use admin grants, and when retrying it prompted me:
'ADVERTENCIA: An existing Chocolatey installation was detected. Installation will not continue. For security reasons, this script will not overwrite existing installations.'
Looking at Install.ps1 file, I discovered at 'Test-ChocolateyInstalled' function, that it assumes if '"$env:PROGRAMDATA\chocolatey"' folder exists, chocolatey is installed, but don't. Just removing this folder has fixed my installation and run first script has worked.
Is my first Issue in an opensource project, be kind :)

┆Issue is synchronized with this Gitlab issue by Unito

I'd like to request a feature for Chocolatey; namely, the ability to flag packages out-of-date a la the Arch User Repository (AUR). I think such a feature might be helpful in alerting maintainers of Chocolatey packages to fix 404 errors.

┆Issue is synchronized with this Gitlab issue by Unito

I sometimes want to open a target's parent directory in explorer or to set it as a current directory. However, I don't know how to do it easily.

I want to a new option --simgen-target to simply output target's path. It is easy to combine with Powershell commands like Split-Path.

PS C:\> 7z --shimgen-target
C:\ProgramData\chocolatey\lib\7zip.portable\tools\7z.exe
PS C:\> 7z --shimgen-target | split-path -parent | ii # open in explorer
PS C:\> 7z --shimgen-target | split-path -parent | cd
PS C:\ProgramData\chocolatey\lib\7zip.portable\tools>

┆Issue is synchronized with this Gitlab issue by Unito

I built the following PS snippet to clean my choco bin path (in an admin-shell) from obsolete shim's:

gci C:\ProgramData\chocolatey\bin\*.exe | %{ if( $( & $_.FullName --shimgen-help | Select-String "Target exists: 'False'" -Quiet ) ) { rm $_.FullName } }

I think its helpful, so maybe you want to include it in your documentation. Not sure if this should be included here or there.

┆Issue is synchronized with this Gitlab issue by Unito

Hello,

The package CoolTerm failed automatic verification based on the following error:

"The request was aborted: Could not create SSL/TLS secure channel."

https://gist.github.com/choco-bot/9220df125541e90f4c9b91b42831cbfd#file-install-txt-L342

The browser doesn't show any warnings, and neither do cURL or wget. I've retried verification a few times, but to no avail.

Thanks!

Update

This seems to be starting to affect a number of packages...

• 4k-video-downloader - Exempted
• 4k-stogram - Exempted
• eduke32 - Exempted
• exiftool - Re-run through verifier as latest package version works correctly
• evga-flow-control - Exempted
• 4k-youtube-to-mp3 - Exempted
• w10privacy - Other issue needs to be addressed first before exemption
• openflexure-connect - Exempted
• CoolTerm - Exempted
• minio-server - Exempted

┆Issue is synchronized with this GitLab issue by Unito

In #7 (comment), it is stated that "it would be a violation of terms of use" to access Chocolatey.org packages information outside of choco.

However, I cannot find terms of use anywhere on Chocolatey.org. The privacy policy just talks about privacy policy stuff. There is the legal page on the docs, but I don't see anything like a terms of use for the website there, just things like licensing for choco, and information regarding the actual packages on the community repository.

If I'm just blind and missed it, just point me in the right direction.

The reason I am asking, is that there are lots of things currently accessing information about Chocolatey.org packages outside of choco.

• AU checks if the package version already exists
• repology check the latest version of pretty much every package.
• shields.io has badges with scraped download counts
• Anyone using a Nexus, ProGet, or Artifactory with a proxy repository to Chocolatey.org is getting information about packages outside of choco.

There are probably others (most likely lots of others), but those are the ones I know of. And if accessing information about packages on Chocolatey.org outside of choco is against the TOS, then all of those are then against TOS. So I'd like to read what it actually is.

I do understand the API is not documented, and that no support will be provided. But a lack of documentation and support is very different from use being prohibited by a TOS.

┆Issue is synchronized with this Gitlab issue by Unito

I know it's an odd case to not having C: as the system drive, but I somehow ended up with this setup when installing a second Windows in dual boot in order to keep the old Windows installation until I decide to delete it.

In any case, the installation of chocolatey fails when the running Windows OS is not installed on the C: drive, but (in my case) installed on the F: drive. I have an old Windows install on C: on dual boot, and that Windows install does have chocolatey installed, and therefore the install fails with the message that chocolatey is already installed, despite it not being installed in the current running Windows installation.

I looked at the install.ps1 file, and it seems that you're hardcoding the C:\ProgramData\Chocolatey path once, and another one for $env:SYSTEMDRIVE\ProgramData\Chocolatey.
I believe the first one is causing the issues. However, can both be changed to use $env:PROGRAMDATA instead?

┆Issue is synchronized with this GitLab issue by Unito

When a shim is terminated by a parent process calling the Windows TerminateProcess API (e.g.: a python script starting the shim with subprocess.popen and terminating it with terminate), the shim process is killed but not the target process.

This is problematic when using Selenium with the geckodriver for example. The geckodriver process is left around because the selenium python module terminates the shim rather than terminating the geckodriver itself (see https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/common/service.py for details on how selenium starts/stops the driver).

See also the comments here regarding reports about geckodriver being left around which I suspect are caused by this issue: mozilla/geckodriver#1220 (it was definitely the case for me).

This occurs since the geckodriver choco package uses a shim. I'm submitting this per request of the geckodriver choco package maintainer (http://disq.us/p/1s9oycu).

┆Issue is synchronized with this Gitlab issue by Unito

Hi,
I am trying to install the "swig" package in the Appveyor runs for our "pywbem project. An Appveyor log with choco verbosity turned on is here

Here is the choco output from that run:

choco install -v -y swig
Chocolatey v0.10.8
Installing the following packages:
swig
By installing you accept licenses for the packages.
Progress: Downloading swig 3.0.9... 100%
[NuGet] Installing 'swig 3.0.9'.
[NuGet] Successfully installed 'swig 3.0.9'.
swig v3.0.9 [Approved]
swig package files install completed. Performing other installation steps.
... (many verbose messages)
WARNING: Url has SSL/TLS available, switching to HTTPS for download
Downloading swig 
  from 'https://downloads.sourceforge.net/project/swig/swigwin/swigwin-3.0.9/swigwin-3.0.9.zip'
Progress: 100% - Completed download of C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\swig\3.0.9\swigwin-3.0.9.zip (10.29 MB).
Download of swigwin-3.0.9.zip (10.29 MB) completed.
Extracting C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\swig\3.0.9\swigwin-3.0.9.zip to C:\ProgramData\chocolatey\lib\swig\tools...
... (many verbose messages)
C:\ProgramData\chocolatey\lib\swig\tools
 The install of swig was successful.
  Software installed to 'C:\ProgramData\chocolatey\lib\swig\tools'
Chocolatey installed 1/1 packages. 
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

As you can see, there is no message about generating the shim files.

Here is the relevant part of the choco log file:

2018-05-13 14:20:17,877 3056 [DEBUG] - Calling command ['"C:\ProgramData\chocolatey\tools\shimgen.exe" --path="..\\lib\swig\tools\swigwin-3.0.9\swig.exe" --output="C:\ProgramData\chocolatey\bin\swig.exe"  --iconpath="C:\ProgramData\chocolatey\lib\swig\tools\swigwin-3.0.9\swig.exe"']
2018-05-13 14:20:18,017 3056 [DEBUG] -  [ShimGen] [WARN ] Could not extract icon from associated program. Using default. Error:
2018-05-13 14:20:18,017 3056 [DEBUG] -  [ShimGen]   Selected Icon is invalid
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] Microsoft (R) Visual C# Compiler version 4.7.2558.0
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] for C# 5
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] Copyright (C) Microsoft Corporation. All rights reserved.
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] error CS2001: Source file 'shimgen\generatedfiles\20180513_142017_9551\CommandExecutor.cs' could not be found
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] error CS2001: Source file 'shimgen\generatedfiles\20180513_142017_9551\ShimProgram.cs' could not be found
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] error CS2001: Source file 'shimgen\generatedfiles\20180513_142017_9551\Assembly.cs' could not be found
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] warning CS2008: No source files specified
2018-05-13 14:20:18,064 3056 [DEBUG] -  [ShimGen] [ERROR] ShimGen had an issue creating 'C:\ProgramData\chocolatey\bin\swig.exe'. Please check the logs above.
2018-05-13 14:20:18,080 3056 [DEBUG] - Command ['"C:\ProgramData\chocolatey\tools\shimgen.exe" --path="..\\lib\swig\tools\swigwin-3.0.9\swig.exe" --output="C:\ProgramData\chocolatey\bin\swig.exe"  --iconpath="C:\ProgramData\chocolatey\lib\swig\tools\swigwin-3.0.9\swig.exe"'] exited with '1'

In a related project (M2Crypto), choco installs swig and does generate the shim files, like in this Appveyor run:

choco install -r -y swig
Installing the following packages:
swig
By installing you accept licenses for the packages.
Progress: Downloading swig 3.0.9... 100%
swig v3.0.9 [Approved]
swig package files install completed. Performing other installation steps.
WARNING: Url has SSL/TLS available, switching to HTTPS for download
Downloading swig 
  from 'https://downloads.sourceforge.net/project/swig/swigwin/swigwin-3.0.9/swigwin-3.0.9.zip'
Progress: 100% - Completed download of C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\swig\3.0.9\swigwin-3.0.9.zip (10.29 MB).
Download of swigwin-3.0.9.zip (10.29 MB) completed.
Extracting C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\swig\3.0.9\swigwin-3.0.9.zip to C:\ProgramData\chocolatey\lib\swig\tools...
C:\ProgramData\chocolatey\lib\swig\tools
 ShimGen has successfully created a shim for swig.exe
 ShimGen has successfully created a shim for ccache-swig.exe
 The install of swig was successful.
  Software installed to 'C:\ProgramData\chocolatey\lib\swig\tools'
Chocolatey installed 1/1 packages. 
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

What do I need to do in order to get the shim files generated?

┆Issue is synchronized with this Gitlab issue by Unito

This would for example enable us to create a shim like:
shimgen.exe -p C:\python36\python.exe" -c "${SHIM_TARGET_LOCATION}\..\Scripts\foo.py" -o foo.exe

┆Issue is synchronized with this Gitlab issue by Unito

What You Are Seeing?

Chocolatey installer no longer uses proxies even though chocolateyProxyLocation is set.
This leaves chocolatey installation in an unfinished/broken state where the only thing that happens is the creation of an empty C:\ProgramData\Chocolatey\lib\chocolatey folder. See related issue here: #3.

What is Expected?

Chocolatey installer to use proxies when chocolateyProxyLocation is set.

How Did You Get This To Happen? (Steps to Reproduce)

• Set a proxy to use for installing chocolatey: $env:chocolateyProxyLocation="http://proxy.mycorp.com:81"
• Run the installer: .\install.ps1

Output Log

PS C:\Windows\Temp> $env:chocolateyProxyLocation="http://proxy.mycorp.com:81"
PS C:\Windows\Temp> .\install.ps1

Forcing web requests to allow TLS v1.2 (Required for requests to Chocolatey.org)

Getting latest version of the Chocolatey package for download.

Not using proxy.

Exception calling "DownloadString" with "1" argument(s): "Unable to connect to the remote server"

At C:\Windows\Temp\install.ps1:219 char:5



*     (Get-Downloader $url @ProxyConfiguration).DownloadString($url)
*     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  * CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
  * FullyQualifiedErrorId : WebException                                                                                                                                                                                                      Getting Chocolatey from .                                                                                               Downloading  to C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\chocoInstall\chocolatey.zip                   Not using proxy.                                                                                                        Exception calling "DownloadFile" with "2" argument(s): "The path is not of a legal form."                               At C:\Windows\Temp\install.ps1:261 char:5                                                                               +     (Get-Downloader $url @ProxyConfiguration).DownloadFile($url, $fil ...                                             +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                     + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException                                               + FullyQualifiedErrorId : ArgumentException                                                                                                                                                                                                 Extracting C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\chocoInstall\chocolatey.zip to C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\chocoInstall                                                                      Microsoft.PowerShell.Archive\Expand-Archive : The path                                                                  'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\chocoInstall\chocolatey.zip' either does not exist or is
not a valid file system path.
At C:\Windows\Temp\install.ps1:517 char:5
*     Microsoft.PowerShell.Archive\Expand-Archive -Path $file -Destinat ...
*     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  * CategoryInfo          : InvalidArgument: (C:\Users\WDAGUt...\chocolatey.zip:String) [Expand-Archive], InvalidOpe
   rationException
  * FullyQualifiedErrorId : ArchiveCmdletPathNotFound,Expand-Archive

Installing Chocolatey on the local machine
& : The term 'C:\Users\WDAGUtilityAccount\AppData\Local\Temp\chocolatey\chocoInstall\tools\chocolateyInstall.ps1' is
not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or
if a path was included, verify that the path is correct and try again.
At C:\Windows\Temp\install.ps1:528 char:3


* & $chocoInstallPS1
*   ~~~~~~~~~~~~~~~~
  * CategoryInfo          : ObjectNotFound: (C:\Users\WDAGUt...ateyInstall.ps1:String) [], CommandNotFoundException
  * FullyQualifiedErrorId : CommandNotFoundException

Ensuring Chocolatey commands are on the path
Ensuring chocolatey.nupkg is in the lib folder

Context

The issue appears to be in this bit of code (cannot find the GH repo for this):

    if (-not ($ProxyUrl -and $ProxyCredential)) {
        Write-Host "Not using proxy."
        $downloader.Proxy = $null
    }

This appears to require that both ProxyUrl and ProxyCredential is set despite the code seemingly handling cases where ProxyCredential isn't set. See output from my run below:

    Write-Host $ProxyUrl  # => http://proxy.mycorp.com:81
    Write-Host $ProxyCredential  # => empty string
    Write-Host ($ProxyUrl -and $ProxyCredential)  # => False
    Write-Host $(-not ($ProxyUrl -and $ProxyCredential))  # => True

Changing -not ($ProxyUrl -and $ProxyCredential) to -not ($ProxyUrl -or $ProxyCredential) fixed this issue for me.

┆Issue is synchronized with this GitLab issue by Unito

just noticed the "Profile" link on https://chocolatey.org/packages is broken. Instead of my profile it's pointing to "https://chocolatey.org/account/Profiles", which doesn't exist

Please see the issue which was not there a day ago
chocolatey/cChoco#151

┆Issue is synchronized with this GitLab issue by Unito

This is a problem for GUI applications which connect back to the parent console to, for example, display help on their command-line options when invoked from the command-line. For an example, Mouse Jiggler, a GUI app, when invoked with -h, produces:

114>C:\ProgramData\chocolatey\lib\mouse-jiggler\tools\MouseJiggler.exe -h
115>MouseJiggler:
  Virtually jiggles the mouse, making the computer seem not idle.

Usage:
  MouseJiggler [options]

Options:
  -j, --jiggle               Start with jiggling enabled. [default: False]
  -m, --minimized            Start minimized. [default: False]
  -z, --zen                  Start with zen (invisible) jiggling enabled. [default: False]
  -s, --seconds <seconds>    Set number of seconds for the jiggle interval. [default: 1]
  --version                  Show version information
  -?, -h, --help             Show help and usage information
  
115>

Which it gets the ability to display by reconnecting to the console of its parent process, usually in this case the CLI, by calling:

Kernel32.AttachConsole (dwProcessId: Helpers.AttachParentProcess);

and detaching from it again once it knows that no display is necessary.

But, of course, when invoked via the shim created by Chocolatey, the shim is the parent process and has no console, as GUI apps do, and so mousejiggler -h exits without displaying anything.

It would be useful, thus, if the generated shim could use the same technique to preserve the console of the parent process, so that GUI apps invoked from the command-line would retain the option of accessing it.

┆Issue is synchronized with this Gitlab issue by Unito

http://ferventcoder.com/contact.aspx returns a 500 server error

Via shimgen.license.txt
then as directed go to http://ferventcoder.com and then click on the contact link.

┆Issue is synchronized with this Gitlab issue by Unito
┆Milestone: 1.0.0

Assuming we have installed different versions of a package using choco:

choco install package --version 1.2.3 -my
choco install package --version 2.0.0 -my

It would be nice to allow using the same shim-file with a version parameter:

$ package --shimgen-help
[shim]:
=========
Shim Help
=========

This is a shim, generated by Chocolatey's ShimGenerator (shimgen).
This shim calls a target with the following settings:
 Target: 'C:\ProgramData\chocolatey\lib\package.2.0.0\tools\package.exe'
 Target exists: 'True'
 Working directory: 'C:\WINDOWS\system32'
 GUI: 'False'
 Wait for exit: 'True'
 command (optional): ''

$ package -packageArgs --shimgen-version 1.2.3  --shimgen-help
[shim]:
=========
Shim Help
=========

This is a shim, generated by Chocolatey's ShimGenerator (shimgen).
This shim calls a target with the following settings:
 Target: 'C:\ProgramData\chocolatey\lib\package.1.2.3\tools\package.exe'
 Target exists: 'True'
 Working directory: 'C:\WINDOWS\system32'
 GUI: 'False'
 Wait for exit: 'True'
 command (optional): ''

It should also work if the target is Target: 'C:\ProgramData\chocolatey\lib\package\tools\package.exe'

┆Issue is synchronized with this Gitlab issue by Unito

Over the last weeks, I noticed a new behavior across all my Windows devices managed via chocolatey. At first, the chocolatey community server won't be seen as source, so no package would be updated. Trying this two to three times in a row, it is finally able to see what packages can be updated. But then, there's a high likelihood that this process will hang:

You have autohotkey.portable v1.1.33.05 installed. Version 1.1.33.06 is available based on your source(s).
Progress: Downloading autohotkey.portable 1.1.33.06... 99%

After some minutes, chocolatey decides to skip the package:

utohotkey.portable not upgraded. An error occurred during installation:
 Timeout für den Vorgang wurde überschritten.
autohotkey.portable package files upgrade completed. Performing other installation steps.
The upgrade of autohotkey.portable was NOT successful.
autohotkey.portable not upgraded. An error occurred during installation:
 Timeout für den Vorgang wurde überschritten.

It hangs most of the time around 90, because the progress hits the 90%-range in an instant. Trying to re-run cup all -y a few times, and it manages to get all package updates at some point.

This is happening on four devices with different versions of Windows 10 (2019-2020 releases) and they are connected to WiFi and Ethernet. I didn't notice these connectivity issues with anything else than choco/chocolatey community server.

I'm not sure this is a bug, but it is an undesired (and maybe unavoidable) result...

I am working on a couple packages (fastcopy.*) that need to use AutoHotKey. I could not get the exitcode the AHK script was supposed to return. It turns out, the actual AutoHotKey would return the exitcode (viewed as $process.exitcode or %errorlevel%), but I was having problems because I was simply calling "AutoHotKey" and relying on the path that included the shim (in Chocolatey\bin).

For example, a sample AHK script:

SetTimer, TooLong, 5000

msgbox, Testing!
ExitApp

TooLong:
ExitApp, 666

Doing this:

$Proc = start-process -filepath 'c:\programdata\chocolatey\lib\autohotkey.portable\tools\autohotkey.exe -argumentlist $AHKfilePath -passthru

causes Write-Host $proc.exitcode to return a "0" if the message box was clicked and "666" if it was left to close on it's own after 5 seconds. That is the expected behavior.

However, using the shim (which is on the path, but not necessarily the first instance of "autohotkey" encountered in the path) like so:

$Proc = start-process -filepath autohotkey -argumentlist $AHKfilePath -passthru

Will always return "0" and do so before the script is finished. (I.E. it is returning the successful start of the script.)

If I adjust for the shim:

$Proc = start-process -filepath autohotkey -argumentlist $AHKfilePath,'--shimgen-waitforexit' -passthru

I get a black, cmd window until the script exits, but I do get the correct exitcode.

I can't seem to find a way to get the AutoHotKey shim to run a "clean/hidden" script AND return the exitcode.

Of course, there is an argument to be made that the full AutoHotKey path should be used, but part of the purpose of shims is to avoid tracking down the full path, and AHK users may not realize their calls for autohotkey are passing through a shim that is "breaking" the expected behavior. Heck, it took me a few hours and a post to the AHK forums to identify the issue!

As I said, maybe this cannot be fixed, but I thought it should be pointed out as a "deficiency" for the record.

I still have much gratitude for the excellent work you do, so thank you.

┆Issue is synchronized with this Gitlab issue by Unito

When viewing the moderation package page on the website, the total amount of packages listed includes the packages that are also waiting for maintainers to update the package.
This can cause some confusion at times as these are not really packages that are ready for moderation, and thus reflects that the moderation queue is larger than what it is.

My suggestion is to update this list of packages to only mention those packages that are actually in the queue and are ready for moderation (be it human moderation or automatic moderation through the verifier/validator).

An example of such an update could perhaps be similar to:

or

┆Issue is synchronized with this GitLab issue by Unito

The following proposal is a simple way for package authors to specify which executables to create a shim for. It removes the need to create .ignore files to prevent an exe being shimmed and allows batch files (.bat and .cmd) to be shimmed without having to use Install-BinFile. It is completely compatible with the current behaviour.

.shiminclude files

A .shiminclude file specifies executables that Chocolatey should generate a shim for. This mechanism provides an opt-in alternative to the default behaviour, which is to automatically shim all .exe files found in the package unless there is a matching file suffixed .ignore.

Each line in a .shiminclude file specifies a path relative to the package's tools directory. This can point to either a specific file type (.exe, .bat or .cmd), or to a directory or group of directories in which to search for .exe files.

Format

• A .shiminclude file is UTF-8 encoded without a BOM.

• A blank line matches no directories or files.

• A line starting with # serves as a comment. Put a backslash \ in front of the first hash for paths that begin with a hash.

• An optional prefix ! negates the path. Put a backslash \ in front of the first ! for paths that begin with a literal !.

• A backslash \ or a forward slash / can be used as a directory separator.

• The ? wildcard matches zero or one character except a directory separator.

• The * wildcard matches zero or more characters except a directory separator.

• The order of entries is not considered: duplicates are skipped and negated paths are irrevocable.

Usage

• A .shiminclude file must be located in the package's tools directory and its entries must be relative paths from this location. If an entry resolves to a location outside the package directory it will be skipped. If no .shiminclude file is found, Chocolatey will search for .exe files to shim.

• Chocolatey will not search for .exe files to shim if the .shiminclude file is empty, or contains only blank/comment entries.

• An entry is treated as a path to a file if it ends with an .exe, .bat or .cmd extension, otherwise it is taken as a path to
  a directory.

• If a matching file suffixed .ignore is found, a shim will not be generated.

Examples

The following examples assume that a package has installed its software into the <pkg>\tools\prog directory, where <pkg> is the location of the package. The .shiminclude file is located at <pkg>\tools\.shiminclude.

• prog\sbin\prog.exe matches the <pkg>\tools\prog\sbin\prog.exe file.

• prog\sbin matches all .exe files in <pkg>\tools\prog\sbin.

• prog\* matches all .exe files in all top level directories in <pkg>\tools\prog.

• prog\sbin\prog?.exe matches <pkg>\tools\prog\sbin\prog.exe and <pkg>\tools\prog\sbin\prog2.exe.

• The file extension must be included to match other file types. For example prog\sbin\prog3.bat matches the <pkg>\tools\prog\sbin\prog3.bat file, while prog\*\*.bat matches all .bat files in all top level directories in <pkg>\tools\prog.

┆Issue is synchronized with this Gitlab issue by Unito
┆Link To Issue: https://gitlab.com/chocolatey/collaborators/shimgen/-/issues/37

When running SysInternals handle.exe through the shim, regular memory leaks develop which culminate with a catastrophic crash of the shim.
These errors do not occur when the shim is bypassed and handle.exe is called directly.

OS: Windows Server 2008 R2 Standard, Windows Server 2012 R2 Standard

Error log 1:
Faulting application name: handle.exe, version 0.2.2.0
Faulting module name: KERNELBASE.dll
Exception code: 0xe0434352
Faulting application path: C:\ProgramData\chocolatey\bin\handle.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll

Error log 2:
Application: handle.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.Win32Exception
Stack:
at shim.ShimProgram.Main(System.String[])

┆Issue is synchronized with this Gitlab issue by Unito

There are a good number of packages that are out of date, some by a couple weeks, some by several months or longer. There should be a way for users to report when a version available through Chocolatey is older than the latest version available online, and how far out of date it is. Then that info should be clearly and readily visible to make it easier to avoid installing packages that aren't being maintained and also draw attention to them so they can be updated. This could be done by a big red notice on the package info page and/or by coloring the package, e.g. green for up-to-date, yellow for out of date by a month or less, indicating it's likely being maintained but it's just lagging a bit, orange for 1-3 months, and red for >3 months.

see sample in screenshot:

• shimgen called via Chocolatey Install-BinFile

┆Issue is synchronized with this Gitlab issue by Unito

Like a .shimgen file that tells you what to ignore, what is a gui, and whatever else. (A shim director)

It could be some sort of chocolatey.ini file as well for adding other things as those became available. Or it could be enhancements to the nuspec.

The relevant conversation:

UPDATE: As Chocolatey Gitter chat is now unavailable, I've added a screenshot of the Gitter chat.

┆Issue is synchronized with this Gitlab issue by Unito
┆Link To Issue: https://gitlab.com/chocolatey/collaborators/shimgen/-/issues/38

Is there any Published API to access the chocolatey packages information with out installing choco

I used chocolaty to install syncthing and update it regularly as well.

Here is a log of the last update:

syncthing v1.11.1 [Approved]
syncthing package files upgrade completed. Performing other installation steps.
Extracting 64-bit C:\ProgramData\chocolatey\lib\syncthing\tools\syncthing-windows-amd64-v1.11.1_x64.zip to C:\ProgramData\chocolatey\lib\syncthing\tools...
C:\ProgramData\chocolatey\lib\syncthing\tools
Environment Vars (like PATH) have changed. Close/reopen your shell to
 see the changes (or in powershell/cmd.exe just type `refreshenv`).
 ShimGen has successfully created a shim for syncthing.exe
 ShimGen has successfully created a shim for syncthing.exe
 ShimGen has successfully created a shim for syncthing.exe
 ShimGen has successfully created a shim for syncthing.exe
 ShimGen has successfully created a shim for syncthing.exe
 ShimGen has successfully created a shim for syncthing.exe
 The upgrade of syncthing was successful.
  Software installed to 'C:\ProgramData\chocolatey\lib\syncthing\tools'As you see here the 1.11.1 version of syncthing was installed, and ShimGen reported that it successfully created shims. However starting syncthing via the shim starts an old version:

PS C:\> & 'C:\ProgramData\chocolatey\bin\syncthing.exe'
[monitor] 16:33:13 INFO: Log output saved to file "C:\Users\username\AppData\Local\Syncthing\syncthing.log"
[start] 16:33:13 INFO: syncthing v1.9.0 "Fermium Flea" (go1.15.1 windows-amd64) [email protected] 2020-08-28 05:48:25 UTC

I would have expected that the most current version is started.

The reason is probably that the syncthing chocolatey packages installs multiple versions and shingen uses lexical order for creating the shims:

PS C:\> ls C:\ProgramData\chocolatey\lib\syncthing\tools\


    Directory: C:\ProgramData\chocolatey\lib\syncthing\tools

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          2020-11-03    16:16                syncthing-windows-amd64-v1.10.0
d----          2020-11-03    12:51                syncthing-windows-amd64-v1.11.1
d----          2020-11-03    16:16                syncthing-windows-amd64-v1.6.1
d----          2020-11-03    16:16                syncthing-windows-amd64-v1.7.1
d----          2020-11-03    16:16                syncthing-windows-amd64-v1.8.0
d----          2020-11-03    16:16                syncthing-windows-amd64-v1.9.0
-a---          2020-11-03    16:16            425 chocolateyInstall.ps1
-a---          2020-11-03    16:16          17175 LICENSE.txt
-a---          2020-11-03    16:16        9788512 syncthing-windows-386-v1.11.1_x32.zip
-a---          2020-11-03    16:16       10063860 syncthing-windows-amd64-v1.11.1_x64.zip
-a---          2020-11-03    16:16            523 VERIFICATION.txt

IDK if this is a shimgen, a chocolatey or a syncthing packaging issue.

┆Issue is synchronized with this Gitlab issue by Unito

It would be very useful to create executables with --shimgen-usetargetworkingdirectory as default argument. Cause many so-called portable apps expecting the config file in the current working directory. E.g. the executable for Regshot in $env:ChocolateyInstall\bin\Regshot-x64-Unicode.exe can't find the regshot.ini if not executed in $env:ChocolateyInstall\lib\regshot\tools\. So you always have to run $env:ChocolateyInstall\bin\Regshot-x64-Unicode.exe --shimgen-usetargetworkingdirectory to start Regshot. The WOX launcher is another example which creates an image directory in the current working directory. It would be great to have these applications in the $PATH.

┆Issue is synchronized with this Gitlab issue by Unito

Last Friday I was browsing through the package list on https://chocolatey.org/ and noticed that when I would go from the current page to the next, the content would sometimes be the same, even though the page # in the address bar did change. I would also go from D to G to C to D again when going forward. Going back a page was even worse.
Today I thought I would try again & noticed that it says "There are 8384 Community Maintained Packages" when Popularity is selected, but when changed to A-Z that # changes to 8190. When left as Popularity, page 2 shows 4952 & when refreshing the page, jumps to 8191. Chocolatey GUI isn't even giving an option to go to a 2nd page any more. CGUI as well as the page through Chrome, Firefox, Brave & Waterfox all the same experience on 2 different Windows 10 machine, 1909 & 20H2. I even tried the page on my ArchLinux machine with the same outcome.
Not sure what is going on, but please resolve.

┆Issue is synchronized with this Gitlab issue by Unito

Recently I wanted to use Chocolatey on a Windows Server 2012 R2 Core trimmed down so much that even the 32-bit subsystem (WoW64) was not present. This posed no problem for choco.exe or PowerShell, but there was the issue of actually installing Chocolatey. The existing install.ps1 uses 7-Zip (7za.exe) by default, which is a 32-bit application and won't work on such a system. Manually switching to the alternate method supported by install.ps1 would not help, because the system had PowerShell 4.0 (so no Expand-Archive cmdlet) and no GUI (so no unzipping by Explorer).

I was able to fix this quickly by hacking install.ps1 to use the ZipFile class present in .NET 4.5 and later, but it motivated me to take a long look at how unzipping is done in that script and I came up with a few improvements.

My thoughts were:

all systems still supported by Microsoft today have a builtin mechanism for unzipping (and I do not mean Explorer);
the install script should be as easy to use as possible, ideally not require the user to tweak anything;
since some users are inconvenienced by an additional download, and it reduces the reliability of the install process, avoid doing that.
I changed the script so that it attempts these unzip methods in order, until one succeeds or all fail:

Expand-Archive - available with PowerShell 5+
System.IO.Compression.FileSystem - available with .NET 4.5+
7-zip - requires additional download, does not work on pure 64-bit systems (Server Core with WoW64 subsystem removed)
Windows Explorer decompresion - does not work on Server Core
Method 1) should work on all modern systems (Win10, Server 2016+).
Method 2) covers older systems still supported by Microsoft (Win8.1, Server 2012 and 2012 R2).
Methods 3) and 4) remain for compatibility with even older, out-of-support OSes (such as Win7).

The user is able to control the list of methods by setting the chocolateyUnzipMethods environment variable to a list (separated by commas, semicolons, pipes or spaces) of method names, chosen out of this set:
PowerShell
DotNet
SevenZip
Explorer

For backward compatibility, the chocolateyUseWindowsCompression environment variable is still recognized, and if set to true and chocolateyUnzipMethods is not set, the method list becomes 'PowerShell,DotNet,Explorer'.

This change brings the following benefits:

support for Server 2012/2012 R2 Core with 32-bit subsystem (WoW64) removed;
no need for additional 7-Zip download on modern OSes;
automatic fallback, so admins should no longer need to manually set environment variables and retry.

This issue was originally raised by jberezanski on internal issue.

┆Issue is synchronized with this Gitlab issue by Unito

When I open a gui application shim, it first quickly opens a console window. This can be very annoying when using an alternative console like ConEmu which then everytime gets a new tab.

┆Issue is synchronized with this Gitlab issue by Unito

I have an automated script to install chocolatey and the package scriptcs. This is on Windows Server 2016.

It works fine when installing as Administrator, but when executed as SYSTEM account, installation fails.

The choco install scriptcs command exits with exit code 1, and here is the relevant part from chocolatey.log:

[DEBUG] - Calling command ['"c:\programdata\chocolatey\tools\shimgen.exe" --path="..\\lib\ScriptCs\tools\scriptcs.exe" --output="c:\programdata\chocolatey\bin\scriptcs.exe"  --iconpath="c:\programdata\chocolatey\lib\ScriptCs\tools\scriptcs.exe"']
[DEBUG] -  [ShimGen] [WARN ] Could not extract icon from associated program. Using default. Error:
[DEBUG] -  [ShimGen]   Format not recognized by IconLib
[DEBUG] -  [ShimGen] Microsoft (R) Visual C# Compiler version 4.6.1586.0
[DEBUG] -  [ShimGen] for C# 5
[DEBUG] - Command ['"c:\programdata\chocolatey\tools\shimgen.exe" --path="..\\lib\ScriptCs\tools\scriptcs.exe" --output="c:\programdata\chocolatey\bin\scriptcs.exe"  --iconpath="c:\programdata\chocolatey\lib\ScriptCs\tools\scriptcs.exe"'] exited with '1'
[DEBUG] -  [ShimGen] Copyright (C) Microsoft Corporation. All rights reserved.
[DEBUG] -  [ShimGen] This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240
[DEBUG] -  [ShimGen] error CS0016: Could not write to output file 'c:\ProgramData\chocolatey\bin\scriptcs.exe' -- 'The directory name is invalid. '
[DEBUG] - Attempting to create directory "c:\programdata\chocolatey\.chocolatey".
[DEBUG] -  [ShimGen] [ERROR] ShimGen had an issue creating 'c:\programdata\chocolatey\bin\scriptcs.exe'. Please check the logs above.

How to reproduce

Create a bat file, e.g. install.bat in C:\ with following content:

powershell.exe -Command "iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex"

c:\programdata\chocolatey\choco.exe install -y scriptcs
echo %ERRORLEVEL%

Add the script to be run as a scheduled task:

schtasks /create /tn Warmup /sc minute /mo 5 /tr "'C:\install.bat' > c:\install.log" /ru system

Wait for task to run or start it manually. You will now see that scriptcs.exe does not exist in C:\ProgramData\chocolatey\bin

┆Issue is synchronized with this Gitlab issue by Unito

If you install a GUI app with Chocolatey, it generates a GUI shim as expected. Running this GUI shim executable from a cmd.exe or powershell.exe results in the shim running without a parent process.

Example:-

• Run putty.exe directly from CLI and it runs with cmd.exe as it's parent
• Run putty.exe shim from the CLI and it runs without a parent

For normal apps, this isn't an issue but for my proxy server which uses AttachConsole() to write to the console (if invoked from one), it doesn't work since it cannot find it's parent console.

Opening this issue since you'd expect the shim to run as a child process just like the application it is shimming.

┆Issue is synchronized with this Gitlab issue by Unito

┆Issue is synchronized with this Gitlab issue by Unito

Package icons should not be linked to directly from GitHub raw. However, I have found that many maintainers still are linking to GitHub raw.

Therefore, it would be nice if the validator could check if the iconUrl is using GitHub raw.
The links can be in a couple of formats, but I think just checking for the domain name would work.

The two that I am aware of are:
raw.githubusercontent.com
github.com

┆Issue is synchronized with this Gitlab issue by Unito

Give the process a little time to handle Control+C before nuking it.

┆Issue is synchronized with this Gitlab issue by Unito

I frequently run across packages where the maintainers have not thought to make an executable shim, so I want to do that after the fact, after it's been installed. How can that be done? Or is this use case not allowed for?

The FAQ entry:

Is shimgen free for use?
Only in the context of using it with Chocolatey. It has a specific license granted to distribution with Chocolatey that is should be used only in the context of Chocolatey and not separately.

...is a bit murky to me. Does this mean it can only be used by people making choco packages and not by people merely using chocolatey?

┆Issue is synchronized with this Gitlab issue by Unito

Thousands of ShimGen generated shim - shim - shim - shim processes is created. I downgraded pandoc again and rebooted, but the same problem exists, which leads me to believe there is another problem than with this package alone.

┆Issue is synchronized with this Gitlab issue by Unito