Support Forum

Hi Cubert.

Appreciate the speedy response and update to the choc shim issue. I have been delving into the script a little further and believe i have identified further issues with the subscript file GetPKGVersion.ps1

When running this against the default active package list it was returning some confusing version information for chocolatey packages when using search -r $package

For example if you run in isolation

$package = "firefox"
choco search -r $Package

the resulting list ranks alphabetically with the top result being
adblockplusfirefox|0.0.0.2

This corresponds with the version being reported back into the application manager for firefox which in turn correlates with the final part of GetPKGVersion.ps1 where it splits the results into an array and selects item [1]


using choco search -r --exact $package returns the correct package version information for the two that I have tested (Dropbox, which returned package name ARQ and version 7.21.2. And Firefox)

However when i have modified the running of this script in the :MASTERVERSIONSTART block on line 318 to include the --exact flag on both Choco SEARCH and choco LIST, it has seemingly stopped returning the package info back to the log messages and subsequently the application manager itself see below screenshots However the correct versions, without names are then returned into the command results field, where the below highlighted field was displaying 0.0.0.2 previously now shows 116.0.3 which is the correct latest stable version for firefox
This all seems to indicate that the way chocolatey returns information from choco search -r $package has changed in a way the script is not prepared for and that the --exact field would need to be integrated into the repo version scan segments as well as the 3 other uses of GetPKGVersion.ps1 throughout. I am however not able to figure out why the command outputs the expected value but this is not passed to the log messages or seemingly the table which stores repo versions. As testing the GetPKGVersion.ps1 script in isolation, with the exact flags, does produce the expected results. getpkgtest.png

Awesome find, I did see that and fixed it in latest build (due out soon).

I have made another change in the latest build, I have had several MSP get confused as to how this plugin operated. They wanted to compare it to Chocolatey for Automate when in fact the tool in Habitat is more fashioned after App Genie.

The differences is that Chocolatey for Automate will install and update apps via automation where App Genie only updates apps that are installed via Chocolatey. So a MSP approves a bunch of apps and waits to see them deployed and nothing happens.

I believe if I take POLL from everyone whom may respond, if they would want App Genie or C4A as a tool in Habitat that the majority would say C4A.

This has pushed me to do a quick redesign as of 1.0.1.38, 90% of the App Manager will work the same as now, look the same and so on but there is now a new button at the client level called "Enable Client Applications". This will open a window that will display the current list of Approved Applications (active) from the global list. You will be able to independently enable and disable each package allowed for the client in this list. Each client will have their own list of enabled applications.

Applications enabled at the client level will auto install and auto update.

Make sure to add Chocolatey as a approved package and chocolatey-core.extension as a approved package.

Script has been updated and should now correctly capture local and repo versions.

I'll post the updates soon as we finish our testing.

Here is the new build, Link is at the bottom of post.

viewtopic.php?t=6287