The command

choco list -lo

lists the installed packages. But how do I determine where a Chocolatey application installs? So far I've had to hunt around for them.

Some examples:

  • NUnit goes to Program Files (x86)
  • WGET goes to %ALLUSERSPROFILE%\chocolatey\bin and %ALLUSERSPROFILE%\chocolatey\lib\[Package Name]\tools
  • ConsoleZ went to %ALLUSERSPROFILE%\chocolatey\lib\[Package Name]\tools

Is there a flag on choco list that will tell me where they went? ChocolateyGUI doesn't seem to do this either.

Sort of like Debian's:


Or RedHat's:

rpm -ql [package-name]

Or YUM's repoquery:

repoquery --list [package-name]


brew list [package-name]

Currently, there is no way to do what you are asking.

Each Chocolatey package is unique in the sense that it could be a wrapper around an MSI or an EXE, or it could be a simple extraction of a compressed archive to a known location i.e. C:\tools, or it could be a PowerShell module that extracts to PSModulePath, or it could be something completely custom.

This is a side effect of the Windows ecosystem, where there are multiple ways to do the same thing. Chocolatey is trying to bring some sort of order to this by providing a mechanism to at least find all the packages that you want in one place, but there is only so much Chocolatey can do.

If you look at things completely differently, it is possible to pass installation arguments to a Chocolatey package using the following:


This could, in theory, alter the installation arguments of an MSI or EXE based Chocolatey package to change where the files are installed to. You can see an example of this approach being used here:


However, this approach is limited. Not everyone takes the time like Matt to mention the possible installation arguments that are possible, and it is quite a convoluted process to extract the installation arguments that are possible to be sent into an MSI or EXE.

In terms of ChocolateyGUI, and as the current maintainer of that product, I can tell you that it does nothing clever in this area :-). It is simply a wrapper around the command line tools that Chocolatey provides, and aims to make it easier for people who don't like using the command line.

  • 2
    There is solution as chocolatey generates shim file for package which keeps the path to executable and exposes the target if called with --shimgen-noop switch, see my answer – maoizm Mar 2 '17 at 9:18
  • 16
    Nearly 3 years later, this is still the thing I find most frustrating about choco: "installed a thing. now....where is it?" – Ben Collins May 16 '17 at 19:53
  • @BenCollins I'm assuming you've upgraded Chocolatey recently as well? It now reports where it installs things - and it has for almost a year now (since 0.9.10). github.com/chocolatey/choco/issues/689 – ferventcoder May 16 '17 at 22:26
  • 3
    "Software installed to '$toolsDir'" Gee, thanks Chocolatey. – blueben May 16 '18 at 12:32
  • 1
    Maybe storing the installation log in some chocolatey directory and give users the ability to retrieve it by package name... – Marcello Romani Sep 17 '18 at 8:54

Unfortunately, not that I know of. I believe the install directory is determined by the package itself. It's not defined in the .nuspec file, and I can't see anywhere that it's explicitly defined in the Chocolatey source code.

Source code: https://github.com/chocolatey/chocolatey

  • This is correct. Looking at the docs for creating a package you'll see that for most packages the MSI installer created by the original software creator defines the installation path. Chocolatey has no idea where the MSI puts files. – heavyd Jul 21 '14 at 21:13
  • This is actually insane. I just installed a bunch of stuff from a choco package, now choco itself can't uninstall those packages and I need to manually find all of them.. Great. – Dmitry Avtonomov Aug 20 '20 at 23:03

If Chocolatey generates a shim for the package, e.g. yourprogram.exe you can tell the path to executable file by the following Powershell command:

$a="path to executable:"
(yourprogram --shimgen-noop | Select-String $a) -split $a | ForEach-Object Trim

This works only if shim is .exe file. This is very common, though some packages generate .ps1, .cmd or even .bat files. In these rare cases this recipe won't work.


I found some usefull stuff in


Surely, these logs contain lots of redundant (for this case) info. But at least they can be viewed to better understand what actually chocolatey does.

cinst notepadplusplus.install -ia "'/D=E:\SomeDirectory\npp'"

If it was an MSI, then usually you could pass -ia:




Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.