Update Uninstall-ChocolateyZipPackage description

[ferventcoder]

This was taken from a message in Google Groups:

If I run Install-ChocolateyZipPackage.ps1 it creates a file chocolatey\lib\\Install.zip.txt, containing all files and folders that were unzipped. I then want to uninstall using UnInstall-ChocolateyZipPackage.ps1. This script expects 2 parameters: PackageName and ZipFileName. The description in the scripts say: ZipFileName: This is the zip filename originally installed. However, if I only pass the zip file name as parameter (in my case .zip), it does not remove the extracted files and folders, because it looks for a file chocolatey\lib\\.zip.txt in stead of chocolatey\lib\\Install.zip.txt. In case I pass Install.zip as parameter the uninstall works fine. Is this expected behaviour? If yes, I think it would make sense to update the parameter description in UnInstall-ChocolateyZipPackage.ps1.

[rockobonaparte]

We collided into this yesterday and found that discussion, which took me here. I was about to open an issue otherwise.

I am unzipping into Program Files instead of ProgramData. I concede that's kind of gross, but was recommended of the group creating the original collateral; the program doesn't mess with the registry, but normally installs to Program Files. It requires a license key that I cannot automate so they recommended I just zip up the mess for distribution for our internal repository. Such is life.

What I had to do was exploit the zipFileName parameter in a gross way:

$derpyInstallPath = "{0}install.zip" -f $packageName
Uninstall-ChocolateyZipPackage -packageName $packageName -zipFileName $derpyInstallPath

That constructs the appropriate path to the install.zip.txt file. After that, my stuff got cleaned up properly.

I saw the code for Uninstall-ChocolateyZipPackage and was thinking that this wouldn't be too hard to deal with but realized there would probably be secondary, whack-a-mole effects for how it performs by default when just using ProgramData.

I wanted to double-check that all the tags are still relevant. This is a roundabout way of me asking if anything was ever done about this. ;)

[pauby]

I would suggest this behaviour needs to be fixed rather than document it.

Unless there is a good reason that the Install text is added to the filename, I'd suggest we stop using it. So when somebody passes package.zip we search for packageInstall.zip.txt (which works for existing uses) and then package.zip.txt. Only if both of those cannot be found do we fail.