the chocolatey package itself will be kept in C:\ProgramData -- if the installer it contains installs itself into whatever location it was told to by the chocolatey package, or whatever default was set. Same for its registration in Programs & Features.
As a rule, we don't go out modifying and re-packaging other vendors' binaries or installers; it's very hard to guarantee that's in any way safe for the end user. Instead, Chocolatey wraps the binary/installer in its own package that it can handle and can run any additional required actions on install/uninstall if the installation has specific requirements.
If the vendor intended it to register in Programs and Features, we're not going to pull that out, it's a core part of the Windows ecosystem. if they provide a way to change the default installation directory, then that can be exposed as part of the Chocolatey package's parameters.
So... sort of? Chocolatey keeps the chocolatey package files in C:\ProgramData\Chocolatey by default, that's part of how it maintains its own package registry of what's installed, etc.
Application installers from those packages may still be installing things into program files as well yeah
choco install nodejsi get a failure (HTTP 401) when it tries to start downloading the nodejs.install package. if i run
nuget install nodejseverything works great. both chocolatey and nuget are using the same source and username/password. running a
nuget installin the chocolatey lib directory followed by a
choco install -fworks since no packages are needed to be downloaded.
<copyright>element indicating that there is no copyright and the software is dedicated to the public domain or should the
<copyright>element just be ommitted?
I'm edited the original extension to include this dependency (KB2919355). This means packages which depend on this extension will need exempt right?
Yes that is likely.
I was trying to say if there is another, maybe better way, I would go for that, in which Verification exempt is not required.
Okay, Got it. Unfortunately at the moment there is not. The reason is that we support back to Windows 7 / PS 2 so we test on a system that has no updates installed so we can make sure that we don't miss any required for a package. Once Windows Server 2008 is no longer supported on Azure this will likely change.