The only issue is in how you include the files - nuget gets confused if the files to include is a backslash. We need to fix that in nuget.core
@ferventcoder True, there were several decisions that lead to a gradle plugin for now ( development team being familiar gradle already, the use of different OS in the build infrastructure and some concerns about adding mono to every buildslave), that said I think a switch to mono later on could very well happen
When handling log files for msi installs are you guys having to create the log folder for the .msi install to succeed? Seems the .msi just errors out if I don't, but looking through other packages for examples I haven't seen anyone manually creating the path for the log file.
This message was deleted
@jesseconnr the MSI Log filter needs ”” and not ’'
it’s super finicky
Evenin' all. This is a curiosity thing. I notice that VirtualBox, which looks like it should be a trusted automatic package, has not been updated to include the recent 5.0.16 release. Not having a clue what I'm doing I looked at the virtualbox.ketarin.xml file, and verified that everything seems kosher. What might be preventing the detection and subsequent chocolatey coating of the new release (which occurred on the 4th according to the website)?
I will take a look, likely tomorrow early to see what is going on with the box running that
Sounds good. Thank you.
@ferventcoder wouldn't using back-ticks be the right way to escape the quotes in the chocolateyInstall.ps1 file?
or are you saying I should double quote even after that?
Either way, creating the directory solves the issue. I've got another problem now where if I install from a package file that doesn't have the version in the name and the package is already installed, it fails with an error about the package not being found in the source. Ex. choco install -fy package.nupkg, if package is already installed it fails unless it's presented as package.1.0.0.nupkg.
@jesseconnr I believe that is fixed. It may only be in the 0.9.10 beta though
If it is not fixed, the issue is logged
The workaround is to call install name -s folder\of\nupkg
Also make sure that it doesn't have .\ on the front of it - it doesn't like that
And ya, the folder must exist for msi logging
Backticks is great, that is what I was saying. Double double quotes will just make it error
hey, I asked a few people what they think about Choco and found out that there are three major concerns which really put them off: 1) the complicated install command, 2) not trusting choco devs and 3) not having its own repository but rather pulling from untrusted servers. Here's the thread for anyone who's interested: https://www.reddit.com/r/sysadmin/comments/4apjvs
It is a copy and paste command, choco is open source and these "untrusted servers" are official servers of the software developers. Didn't read the reddit...
Also for businesses you wouldn't use chocolatey.org but build your own repo
All of these concerns feel like a bit of folks being misinformed. I'll address the thread later
sounds very familiar to what i faced at a previous (very paranoid) enterprise when i pitched (and later set up) chocolatey.
9 times outta 10 it is exactly what you're looking for. so you gotta either change your mind (don't need a central software repo) or change your policy (choco is good)
a room full of managers' jaws dropped when i showed them chocolatey the first time
and there were IT personnel in there. they all agreed it was the way to go.
Just keep in mind most organizations never touch the community repo
The chocolatiest bot this side of the Mississippi
bc3tech gained a level! (Karma: 3)
For relaying those concerns to me to address
An easy way to alleviate some of that concern and add functionality would be for packages to allow specifying the source of the installer instead of embedding the url.
Though you could end up with some version issues I suppose.