Questions about Chocolatey CLI integration in UniGetUI

[gep13]

👋 Hello, my name is Gary, and I am one of the maintainers of the Chocolatey family of projects, and I had some questions about the integration of Chocolatey CLI in to UniGetUI. I thought that raising this as a discussion was the best way to go, but if there is somewhere else that you would like to discuss this, please let me know.

Why is there a version of Chocolatey CLI bundled into UniGetUI, rather than defaulting to using Chocolatey CLI, only if it is installed on the machine (and perhaps providing an ability to install Chocolatey CLI, if it is not detected).

The issue with bundling a version into UniGetUI is that it can become outdated, as new versions of Chocolatey CLI is released. This adds work to the maintenance of UniGetUI.

In addition, running choco list against the bundled version of Chocolatey CLI, will report different packages as being installed, compared to the machine level installation of Chocolatey CLI.

Was there something in how Chocolatey CLI works with UniGetUI that required there to be a bundled version?

[marticliment]

I thought that raising this as a discussion was the best way to go, but if there is somewhere else that you would like to discuss this, please let me know.

Yeah, this is fine 🙂

Why is there a version of Chocolatey CLI bundled into UniGetUI, rather than defaulting to using Chocolatey CLI, only if it is installed on the machine (and perhaps providing an ability to install Chocolatey CLI, if it is not detected).

Some Chocolatey operations require administrator rights to be properly run (for example, update sources), and it was not viable to have the user elevate every single operation (because they are sometimes automated, and there are issues with parsing live output of elevated programs). Therefore, if the user chooses so, Chocolatey will be installed within UniGetUI, on a non-admin location.
If the user already has Chocolatey, or decides to install chocolatey themselves, UniGetUI can work with system chocolatey, but issues may be expected. For the record, if UniGetUI is installed on a machine with chocolatey already installed, UniGetUI will (or at least should) pick that out as the default chocolatey installation.

The issue with bundling a version into UniGetUI is that it can become outdated, as new versions of Chocolatey CLI is released. This adds work to the maintenance of UniGetUI.

I have an automated workflow on my pc, that updates chocolatey before I build a new version. In fact, I used to do the same thing until I was able to migrate to COM APIs. Asynchronous updates also mean that the CLI output can change, and I wouldn't be able to prevent the users from updating and then having a broken integration with UniGetUI.

In addition, running choco list against the bundled version of Chocolatey CLI, will report different packages as being installed, compared to the machine level installation of Chocolatey CLI.

This shouldn't be a thing, unless you are using bundled chocolatey with WinGet, and system chocolatey on a CLI.

[gep13]

@marticliment Apologies for not coming back to you sooner about this discussion. Recently I have taken some time off work, and I am only just getting back to things just now.

I wanted to go and test out a few things with regard to the comments that I made, but I have run into a bit of an issue. Not sure if this is the right place to discuss it, but thought I would start here, and I can always create an issue if required.

I created a new VM so that I could test things out, and I then set about installing UniGetUI. During the installation, I noted that installing Chocolatey was selected:

However, when I go into the Package Managers section when I open UniGetUI, I am seeing the following:

It is saying it can't find choco.exe in a folder called C:\Program Files\UniGetUI\choco-cli\choco.exe however, choco.exe has been placed into my AppData folder, as shown in the screenshot.

Can you help me understand what is going on here? Why it is installing Chocolatey to one folder, but then looking for it in another one? Did I miss something during the installation of UniGetUI?

Thanks

[marticliment]

UniGetUI will be installed machine-wide, but chocolatey will be installed per-user. If another user wants chocolatey, they can either install chocolatey the official way (choco's script) or run the UniGetUI installer again, and it will install chocolatey for the current user.

[gep13]

Is there a way to make this clearer within UniGetUI? It wasn't immediately clear what was going on here. The hard-coded path didn't help, which you are going to fix, I am just wondering if there is another way that this can be communicated to the end-user.

and it will install chocolatey for the current user

I am not sure if this is something that you want to recommend. Chocolatey is intended to be used as a machine level package manager, and having two installed versions of Chocolatey (for different users), who might attempt the installation of the same applications on the machine, will likely cause nothing but problems.

[marticliment]

I suppose that when the path was not found it shouldn't be reported...
I will try to improve the situation

[marticliment]

I reckon this makes more sense:

I will see what I can do to clarify that the installer installs chocolatey for the current user only.

[gep13]

I have just installed UniGetUI again, and I think the additional clarifications do help.

[gep13]

👋 @marticliment back with more questions! 😄

I have just come back to this, as I am still wanting to understand how things are meant / expected to work, as I am having a slightly hard time to understanding the intentions, so I wanted to make sure that I am not missing something.

In the above thread I got into a problem, where UniGetUI was originally installed as an administrator user, and as a result, the local installation of Chocolatey CLI was in that user folder, rarher than another non-admin user that I had created. I created the non-admin due to the warnings that were shown within UniGetUI about not running with administrator permissions.

To take things back to the start, I decided to destroy the VM that I was using and recreate it. This time around I started with a non-admin user and attempted the installation of UniGetUI. This immediately prompted for permissions to perform the installation as a UAC prompt was shown. I used the details of an administrator account that I have, and the installation continued. UniGetUI then came up, but once again it could not find Chocolatey as a Package Manager.

Digging into it, the local copy of Chocolatey CLI had been installed into the admin account that I had used at the UAC prompt, rather than the non-admin user that had started the installation of UniGetUI.

So, I guess my main question is...

How am I meant to install UniGetUI, along with Chocolatey CLI, in a way that it will work without the warning that I initially saw when running UniGetUI in the above thread. I totally might be missing something, so feel free to tell me that I am doing something silly. I am really just trying to understand how things are expected to work, so I can understand a baseline of using UniGetUI and Chocolatey.

Thanks!

[marticliment]

For chocolatey to run first-try, install UniGetUI on a user account with administrator rights. (this does not mean that you will need to run unigetui as administrator, but the installer will require administrator rights). If you install from a standard user and input credentials for admin permissions, you are effectively installing chocolatey for the admin user, and not for the standard one.

in a way that it will work without the warning that I initially saw when running UniGetUI in the above thread

This only will show when UniGetUI has administrator rights (UniGetUI.exe was run as administrator)

[gep13]

So, I guess I am still a little confused, especially by this part...

this does not mean that you will need to run unigetui as administrator

If I am signed into Windows with a user that has administrator rights, how do I tell it to run without administrator rights? Or, are you suggesting that I should temporarily provide a user with administrator rights to perform the installation of UniGetUI, and to then remove the administrator rights?

With the two attempts that I have done to get UniGetUI up and running, these are the steps that I have taken...

First Attempt

1. Create new VM in Azure, default user is created with the name of gep13 and this user has administrator rights
2. Logged into the machine, and installed UniGetUI using artifact from GitHub Releases
3. UniGetUI was installed, and Chocolatey was installed to the gep13 AppData folder
4. Ran UniGetUI by double clicking shortcut on the desktop, and was informed that I was running with administrator privileges, and this was not the correct course of action
5. Created a new non-administrator user called bob on the machince
6. Logged into the machine with the bob user, and double clicked the shortcut on the desktop.
7. UniGetUI ran without warnings about permissions, but unable to find Chocolatey Package Manager

Second Attempt

1. Create new VM in Azure, default user is created with the name of gep13 and this user has administrator rights
2. Logged into the machine as gep13 and immediately created a new non-administrator account bob
3. Logged into the machine as bob and installed UniGetUI using artifact from GitHub Releases
4. During this process, I was required to elevate the process, so used the gep13 user to do this
5. UniGetUI was installed, however, Chocolatey was installed to the gep13 AppData folder
6. Ran UniGetUI by double clicking shortcut on the desktop, and was not able to find Chocolatey Package Manager

Could I please ask that you provide some steps for the recommended way to get UniGetUI installed, along with Chocolatey CLI? Because things really aren't working the way that I would expect them to.

Actually... I have just spoken with a colleague, and he has made a point that I think might have some bearing here. All of the above was done on a Windows Server 2019 VM. He is suggesting that the UAC prompts might be behaving differently on a Client Operating System, compared to Server.

Can you confirm if it is your expectation whether each time you double click the UniGetUI desktop shortcut, that you are prompted with a UAC prompt asking whether you want to run with elevation or not? If that is the case, then this is not happening on Server, and further, if that is the case, then is running UniGetUI on Server something that is supported?

When I get some time, I am going to run some further testing on a Client operating system.

[marticliment]

I don't know how UAC prompts and account security works on Windows Server, but it could be this. On Client Windows install, there is a difference between an administrator user and a process actually being elevated. You can run processes from an administrator users without them actually being elevated. When you elevate the process (you right-click an exe/shortcut -> run it as administrator), it is still ran as the same user, but it now has administrator permissions (for example, it can write to C:\Program Files). When you elevate a process is when you see the UAC prompt, with the Yes/No options.

If you are seeing the "Do not run UniGetUI as administrator" popup this means that the windows image does not support this type of behaviour. In order to get real-world conditions, I'd recommend testing on a local VM created from a Windows 10/11 ISO, and not by prefabbed Azure VMs. In fact, if you test UniGetUI on Windows Sandbox you will experience the same behaviour.

[gep13]

Thank you for confirming all of this. I will do some more testing, and come back if I have more questions.

[gep13]

During some of the above investigations, I noticed a couple of things that I wanted to check with you. It looks like you are also bundling a version of winget.exe (see screenshot below). Is there a reason that you are placing this into the Program Files folder, rather than into a User AppData folder like you are with Chocolatey? And vice versa, is there a reason that you chose to put Chocolatey into an AppData folder, rather than into Program Files?

[marticliment]

The bundled version of winget does not require write permissions on the executable's directory, while chocolatey does. Chocolatey directory is alive, as it has files that will be edited by chocolatey during normal operation. WinGet does not.

[gep13]

The main file that changes during normal operations would be the log file, which is typically contained within the Logs folder of where Chocolatey is installed to. I am not a user of Winget, so I can't speak to what it does, but I am assuming that it must write to a user folder for the logs that it has?

[marticliment]

I am not a user of Winget, so I can't speak to what it does, but I am assuming that it must write to a user folder for the logs that it has?

WinGet stores everything under %localappdata%\Microsoft\WinGet and %temp%\WinGet

[gep13]

When installing UniGetUI onto Windows Server 2019, the bundled version of Chocolatey isn't actually working (see screenshot below), since .NET Framework 4.8 is not installed. I noticed that the UniGetUI is installing the Visual C++ dependency, so I think that it would make sense to also install .NET Framework 4.8 when the option to install Chocolatey is selected.

What do you think?

[marticliment]

UniGetUI is not compatible with Windows Server 2019. See the homepage for more details: https://www.marticliment.com/unigetui/

[gep13]

Thank you for that link. I was actually looking for that information, but I only looked in the project readme.md file, I didn't click through ot the website.

On the website you have:

Windows Server 2019 x64 should work, but WinGet may not work at all

Since you are calling out that WinGet might not work, I personally think an additional note to clarify that .NET 4.8 is a requirement for Chocolatey would be a good idea. Either that, or the UniGetUI installer should handle the installation of .NET 4.8 when the Install Chocolatey checkbox is ticked.

[marticliment]

I will be updating my website, as I was actually not aware that chocolatey required .NET FW 4.8

[gep13]

Thank you for updating the website, I think this will help!

[gep13]

Hello again! I have had some time to come back to look at this, and I have some more questions 😄

This is now my fourth attempt to get things up and running, and I believe that I am making progress.

I am still using a VM in Azure, but this time around I have installed Windows 10. The trick to get things working seems to be to create another local user with admin permissions, and use that, rather than the default admin user that is created when the VM is provisioned. That user seems to have more permissions, which was causing some of the issues that I saw. Things are working much more like you have described previously when I do this.

First question...

When I double click on a package that is coming from the Chocolatey Community Repository, I get taken to a package details page, which looks like this:

Have you thought about rendering the description, which can contain markdown format, so that the headings are rendered correctly?

[marticliment]

I am waiting for CommunityToolkit to release the Markdown Renderer, which is already on beta stage. As soon as it becomes available I plan to integrate both on the description and on the notes.

[gep13]

Sounds great!

[gep13]

Next question...

Is there a way to show which of the list of package managers is "active" on this screen?

Currently, I have to drill down through into each one to see if it is enabled or not:

[marticliment]

Currently not, perhaps it would be a good idea. I will have your idea in mind.

[gep13]

Does UniGetUI work with NuGet v3 feeds? As of Chocolatey CLI 2.x, it does, but I don't seem to be able to find any results from a v3 feed through UniGetUI.

Running choco search Cake.Tool --source nuget I get 63 results, but I don't get any through UniGetUI.

This would suggest that you aren't executing choco search directly, and instead searching in another way. Can you confirm if that is the case?

[marticliment]

No, the internal NuGet implementation (currently) only supports v2. I thought NuGetv3 hadn't been released yet...

[gep13]

The NuGet v3 API (which is a JSON based API rather than an oData one) has been around for quite a while now (several years). With the release of Chocolatey CLI 2.0.1, we included the ability for Chocolatey CLI to use both v2 and v3 feeds.

[marticliment]

Does chocolatey have a public source that uses v3? Do you know if there is v3 documentation somewhere? I have faced issues when implementing NuGet due to a lack of documentation (or at least I couldn't find it)

[gep13]

I ran into an issue when trying to use the system version of Chocolatey, where I wasn't able to add a source through UniGetUI:

Is this a known issue?

[gep13]

If it helps, the more details is...

Starting adding source operation for source=NuGetwith Manager=Chocolatey
Executing process with StartInfo:
 - FileName: "C:\ProgramData\chocolatey\bin\choco.exe"
 - Arguments: "source add --name NuGet --source https://api.nuget.org/v3/index.json -y"
Start Time: "5/22/2025 2:11:04 PM"
Chocolatey v2.4.3
Chocolatey detected you are not running from an elevated command shell
 (cmd/powershell).
 You may experience errors - many functions/packages
 require admin rights. Only advanced users should run choco w/out an
 elevated shell. When you open the command shell, you should ensure
 that you do so with "Run as Administrator" selected. If you are
 attempting to use Chocolatey in a non-administrator setting, you
 must select a different location other than the default install
 location. See
 https://docs.chocolatey.org/en-us/choco/setup#non-administrative-install
 for details.
For the question below, you have 20 seconds to make a selection.
 Do you want to continue?([Y]es/[N]o): 
Timeout or your choice of '' is not a valid selection.
Error serializing type chocolatey.infrastructure.app.configuration.ConfigFileSettings:
 Access to the path 'C:\ProgramData\chocolatey\config\chocolatey.config.18256.update' is denied.
This is try 1/3. Retrying after 400 milliseconds.
 Error converted to warning:
 Access to the path 'C:\ProgramData\chocolatey\config\chocolatey.config.18256.update' is denied.
Error serializing type chocolatey.infrastructure.app.configuration.ConfigFileSettings:
 Access to the path 'C:\ProgramData\chocolatey\config\chocolatey.config.18256.update' is denied.
This is try 2/3. Retrying after 600 milliseconds.
 Error converted to warning:
 Access to the path 'C:\ProgramData\chocolatey\config\chocolatey.config.18256.update' is denied.
Error serializing type chocolatey.infrastructure.app.configuration.ConfigFileSettings:
 Access to the path 'C:\ProgramData\chocolatey\config\chocolatey.config.18256.update' is denied.
Maximum tries of 3 reached. Throwing error.
Access to the path 'C:\ProgramData\chocolatey\config\chocolatey.config.18256.update' is denied.
End Time: "5/22/2025 2:11:07 PM"
Process return value: "1" (0x1)
Could not add source NuGet to Chocolatey

[gep13]

This would suggest that the process hasn't been elevated, even though the toggle for Always run Chocolatey operation with administrator rights has been enabled.

[marticliment]

Can you please open an issue for this? It looks like UniGetUI is not detecting that Elevation is required here.

[gep13]

Once UniGetUI is installed, and it has placed Chocolatey CLI into a custom folder, actually getting Chocolatey CLI installed globally is a bit of a challenge, due to the fact that the $evn:ChocolateyInstall and $env:Path environment variables have been updated. In order to get the Chocolatey CLI to the default location I had to:

• remove the $env:ChocolateyInstall environment variable, otherwise it will attempt to install to that location
• remove entry for UniGetUI from users path environment variable in order to continue

Do you think that this is something that should be documented somewhere in your site?

[marticliment]

I am planning on a document with some faqs about how package managers are integrated with UniGetUI, when I do this I will definitely add this

[gep13]

That would be great! Thank you!

[gep13]

Related to the above, I had a question about expectations about UniGetUI usage of Chocolatey CLI...

Let me explain what I did...

• I installed UniGetUI with all the default settings
• I went into settings and changed Chocolatey to always run elevated
• I searched for WinDirStat and saw it available from Chocolatey, so I installed it
• I searched for VLC and saw it available from Chocolatey, so I installed it
• I then followed the above process to install Chocolatey CLI to its own default installation location
• I changed the setting to Use system Chocolatey which required a restart
• On opening UniGetUI, I was met with the following
  
• As you can see, WinDirStat is now labeled with a source of Local PC and VLC with a source of WinGet, when they were actually both installed through Chocolatey CLI

Is this expected? Or is this not a standard user flow for people using UniGetUI?

[marticliment]

Yes. WinGet detects local installed software, so it will find VLC and WinDirStat (WinGet will wlways find everything, except portable apps). WinDirStat is still found by WinGet, but WinGet wasn't able to correlate it with any WinGet package, hence it shows as Local PC