What it does

Chocolatey lets you install Windows applications quickly from the command line via a central catalog of installation scripts. You could install Git, 7Zip or even Microsoft Office (given a key.) The idea is seamless and quiet installations using a well-known key.

For example, once installed you can do this from and command line:

cinst git

cinst 7zip

cinst ruby

cinst vlc

That's basically it.

The catalog has grown so complete, in fact, that I recently wanted to install DosBox so I could play Zork. I took and chance and just "cinst dosbox" and it worked. THAT is a the promise that Chocolatey makes.

Getting Started with Chocolatey

You can get started by first installing the Chocolatey package manager. Copy paste this line to your command line and run it. (More on the fearfulness of this first step in a moment).

Presumably you like to know what command line stuff is going to do to your computer before you do it, so parse this line out. It's going to launch PowerShell to do the hard work. Nearly every Windows machine has PowerShell these days, and it's PowerShell that makes Chocolatey work.

Some folks have custom profiles so the -NoProfile switch suppresses custom profiles to prevent conflicts during installation. It launches a chunk of PowerShell script that it downloads from https://chocolatey.org/install.ps1/ then executes. Note that it's setting execution policy to unrestricted to do this. To be clear, it's executing code downloaded over the web, so there is a non-zero risk there. It then adds Chocolatey to your path (for this one prompt) so you can use it immediately. It'll be added to future instances of prompts automatically.

Look at https://chocolatey.org/install.ps1 now. It's a very clean and easy to read script. It downloads the Chocolatey installation zip file (which is actually a NuGet package), unzips it and continues the installation by running a scripts in the tools section of the package.

How it works

Chocolatey is a bootstrapper that uses PowerShell scripts and the NuGet packaging format to install apps for you. NuGet is the package management system that Windows Developers use to bring libraries down at the project level. Chocolatey (get it? Chocolatey Nu-Get?) extends that concept to bring applications down at the system level.

Today if you want to get 7Zip, you usually google for it, find the site, figure out the latest version or right version for your system, download it, run it, next next next finish and maybe add it to your path. Chocolatey does that for you.

Chocolatey uses PowerShell scripts (that you never have to think about) that package developers use to chain installations and build dependency trees. Take the internals of a Git installation script for example:

The most important part for you to take away here is the first line. Note that this Chocolatey script is downloading Git from the mSysGit Site. Chocolatey is not changing installers, making installers or hosting installers. It's automating the boring parts of getting software, but it's still getting that software from the same location as always.

Advanced Stuff

Once you learn the basics - and they're pretty basic - there's more depth to Chocolatey to explore. Beyond the cinst and cuninst there's other commands to make installing stuff on Windows easier. Remember, they're all in your PATH so you can call these commands anytime.

Each of these major sources can be called with cinst using the -source parameter like "cinst IISExpress - source WebPI" or using their own aliases for simplicity as shown below.

cwindowsfeatures - If you've ever opened Add/Remove programs then click Install Windows Features in order to setup IIS or Hyper-V then this command is for you. Some examples:

cwindowsfeatures IIS-WebServerRole

cwindowsfeatures Microsoft-Hyper-V-All

cwindowsfeatures TelnetClient

Plus, you can always clist -source windowsfeatures for the complete list.

cwebpi - The Web Platform Installer is a great GUI for downloading any development tools you might need for Web Development on Windows. It's a catalog, an installer, and a chainer. There's also a command-line version of WebPI that Chocolatey integrates with so you can:

Security Issues

This is a prickly one. How do you make a system that lets you install anything directly from the Internet quickly, cleanly, and easily without, well, installing something evil directly from the Internet? You'll want the communication with the server to be secure and the packages trusted, but you'll also want to make sure the packages haven't been tampered with since they were uploaded. There's the inevitable threat of a man-in-the-middle attack. You'll want to watch for malicious packages and enable quick takedowns if one sneaks by.

Security concerns aren't unique to Chocolatey, of course. They are a part of package repositories since their inception. The node npm repository had a security breach in March of 2012, and the folks at andyet explored the issues surrounding it, but also pointed out that personal responsibility has to have a role as well.

Linux's apt-get solves much of this with appropriate uses of cryptography and best practices that can (and should) be emulated. Packages in apt repos are signed with SecureApp, there are warnings if you're using a 3rd party repo or installing an unsigned package.

The Chocolatey team has been very quick to jump on security issues and they are very approachable. They've added SSL where appropriate and are aware of the work to come. If Chocolatey gets big (bandwidth and costs is a question in my mind) perhaps a non-profit organization would step in to help with not only costs, but also security audits and best practices.

Security has a big future aspect of chocolatey. At the present I am the curator and I every day I get an email showing me all of the new packages that went in the day before. I look at all packages from new authors and I typically look at the first version of most new packages from authors I have good contacts with.

I've talked at length with others about having a moderated feed in the aspect of every package, every new version would be approved prior to showing up on the main feed. I am paying attention to how debian does things with multiple feeds and there are thoughts to move in that direction as well.

Security? In the future we are looking at a small group of folks be an approving body for nupkgs. We also talked about showing the hash for the nupkg, and possibly letting folks specify a hash for the installers so chocolatey can verify the things it downloads prior to execution.

Could I make a Chocolatey package called "FormatMyHardDrive?" Sure I could, just like I could ask you to open an admin prompt and format c: /q, but you won't, right? ;)

What's next?

Chocolatey is clearly not meant to be used by your "Gender Non-Specific Non-Technical Parent" and it does have some "competition" in the form of the Ninite GUI installation utility. While still not for the average Joe/Jane and having only a limited catalog, Ninite does fill a gap for the super-user to quickly get the common apps and utilities they want.

Additionally, is Chocolatey really apt-get? It's not installing libraries system-wide, although there's no reason it couldn't. Other open source projects like CoApp would like to be the Windows app-get although CoApp is more of a "system-wide libraries, C++ support, and Unix-like utilities" and Chocolatey is more of a "developer and poweruser utilities and their dependencies."

Chocolatey does install dependencies and you can see that happen yourself by trying out "cinst gitextensions" which itself has a dependency on git. Chocolatey will walk the graph and install what it needs before finally installing gitextensions.

Where Chocolatey, and ultimately Windows itself, falls down is with odd PATHing and install locations. Because Windows doesn't have formal install locations for things and because Chocolatey puts itself first in the PATH, it's possible to get one's self into odd situations where apps that were installed outside of Chocolatey don't line up with apps installed inside. For example, I installed Git with Chocolatey some months ago, then forgot about that version and installed a newer version of Git on my own. However, I kept hitting an old git bug because the Chocolatey version of Git was "first." I believe issues like this have changed with recent builds of Chocolatey, but the point remains: it's hard on Windows today to who installed what low-level utility, when, and where it ended up.

Branding

Now, by no means to I want to take away from the hard work done by Rob and the team, but (and I've said this to Rob before) I really have trouble getting past the name Chocolatey. Sure, there are two ways to spell "Chocolaty," which make it hard at least for me to type "Chocolatey" reliably. The -ey is a theoretically a valid variant spelling, but you can tell that that to the red squiggled underline in Word. But it's less the spelling and more the name itself. It lacks the nerdiness of an "npm," the gravitas of an "apt-get," or the poetic terseness of a "gem." I realize that we are living in a world with companies called Hulu, Yahoo, Microsoft (seriously, MICRO SOFT, what is that?) and Google, but it's worth pointing out that a good name can really take a project to the next level. I'm not sure Chocolatey is the right name for this project, but that's 100% my opinion.

I encourage you, technical reader, to check out Chocolatey for yourself! It's a powerful tool, an engaged and growing community and an interesting piece of tech in its own right.

Is Chocolatey the apt-get Windows users have been waiting for? Sound off in the comments.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

Frank - I *think* it's a joke. There's NuGet which is like the candy "Nougat" http://en.wikipedia.org/wiki/Nougat which is often found alongside Chocolate. So it's "Chocolaty Nougat" except spelled differently. It's a play on words.

One of the best parts of Chocolatey is that you can easily put everything in a batch file or PowerShell script. This means that a large part of setting up a machine can be automated for you.

When I showed this to the IT guys at work, they were meh on it - when I showed them a batch file that pulled Chocolately down then a few packages they fell in love since it would enable them to quickly setup machines in a repeatable way.

Python also has a nice system called easy_install. Now that is without doubt the best name for a system like that.

There also is a system for Java (before Maven and Ivy came along with m2 repositories and p2 provisioning) called JPackage. It's dead now.

ReactOS also has a very nice system called ReactOS Application Manager (Google it for screenshots).

Ivo Limmen

Tuesday, 28 May 2013 09:07:20 UTC

Nice - I hope this project really takes off.I have been waiting for something like for quite a while and been glancing a bit jealously at the linux guys and their apt-get.While this project is definitely not revelant for random users, it has the potential to change the way techy guys like us install and update software on Windows forever.

I've been wondering about the feasibility of using it within environment automation, as the Windows equivalent of yum or apt-get for Chef installs over WinRM but as you said, security would need to be airtight for that sort of system.

Making chocolatey packages is pretty challenging because every programme is packaged differently. Sometimes you'll get lucky and only have to deal with a .msi installer. Then there are other times where it's a self-extracting executable inside a ZIP file that also requires you to fiddle around with environment variables.

It's all worth it though when Scott Hanselman mentions one of your packages in one of his blogs.

Just call it apt-get ... why not? We fight for web standards etc... why not standardize this across OS's ?oh yes, legal issues maybe, but seriously! As a developer we are more and more required to do both win8/linux/android/mac development, do you really think my brain can handle typing apt-get on one system and app-get on another and cinstall on the next, no way, i'll use the GUI then!

Chocolatey is great, I also recommend boxstarter. Boxstarter is built on chocolatey and adds things like running windows update and reboots. Here is how I am using it: https://github.com/fschwiet/fschwiet-boxstarter.

I like the name personally.

fschwiet

Tuesday, 28 May 2013 11:39:32 UTC

Silly me: I thought that one of the main reasons for the Windows Store would be to address EXACTLY this issue. I really think it's sad that after all these years there's not an official solution from MS. PS: Sorry for the rant.

Luiz Angelo Heinzen

Tuesday, 28 May 2013 11:48:36 UTC

@Luiz - It would be used and embraced as well as driver signing has been, I'm sure.

K

Tuesday, 28 May 2013 11:52:48 UTC

The very first thing i do when I do a format ...

1. open ie -> search for choclatey.

2. copy/paste the command to install it

3. cinst googlechrome

4. cinst 7zip

5. cinst tortoisegit

...

One other thing u forgot to mention Scott - when a program updates itself (for example, tortoise git), just type cinst <program> and it updates itself, if a new version is available.

so easy!

now .. if only visual studio was split up into lego pieces instead of one huge app with lots of parts we don't use (eg VB...) and then cvs <part of vs> .. we would all be such productive and happy devs!

I have to say though, despite knowing about Chocolatey for months and using apt-get in Linux for years, I've never used Chocolatey. When I try to understand *why* that is, I can only conclude it's because it's not intrinsic. I feel like package management has to happen at the O/S level to be truly dependable and for the packages to be kept up to date.

But maybe that's just me...

Kent Boogaart

Tuesday, 28 May 2013 12:13:34 UTC

AppGet would be a far better name for this, alas the domain is taken.

But the Powershell command should surely be Get-App.

Jim

Tuesday, 28 May 2013 12:29:01 UTC

Scott -

I'm a big fan of choc, have contributed in small part to the main code itself, and have contributed many packages (some of them rather complex). Rob has done a pretty great job of pushing the project forward and building out the ecosystem in his spare time, and it has come a long way. Unlike some projects where the authors are sponsored by their companies to work on these projects during regular biz hours, Rob isn't afforded the chance to improve it during that time -- it's strictly a passion project on the side.

I agree that there are some rough edges, and I think everyone else on the core team agrees.

Yes, the name has to go -- this was one of the biggest things I saw people repeatedly screwing up when showing them the chocolatey ropes on my team. IMHO, at this point I think it should simply be shortened to stem all commands off of `choc` to not only make things shorter / easier to type, but to also reduce the command space and increase discoverability. There are some fancy ways of doing dynamic tab auto-completion in PowerShell that could be leveraged to make this work like git does. As you mentioned, the whole thing could be rebranded.

I raised the command naming / discoverability issues a while back, but never had time to implement a better approachhttps://github.com/chocolatey/chocolatey/issues/186Note that there is some funky heritage as well with existing commands and running .cmd from inside PowerShell, which then runs a new PowerShell session. IMHO, that stuff should be redone at the same time, to make everything a native PowerShell experience. (I'm a PowerShell first guy myself, but Rob might still use cmd as his go-to.)

Another sticking point is that there is no standardization around checking for previously installed tools, or around the uninstallation process in general. Admittedly, dealing with the wealth of Windows based installer technologies (MSI, NSIS, InnoSetup, InstallBuilder, lots of custom variations, etc) can be a real pain for someone who wants a quick'n'dirty wrapper. This causes a bit of quality variation around packages built by different authors -- some people think of this stuff, while others don't. This ends up being important because of dependency hierarchies. Consider a Visual Studio plugin that requires Visual Studio -- you want the chocolatey Visual Studio installer to recognize VS is installed, and move on... not download 3GB of installer only to run the installer and have it error out because VS is installed already.

I suggested implementing an internal DSL to help push these concepts forward a bit more:https://github.com/chocolatey/chocolatey/issues/160

Another big issue for me is working around transient issues (like packages failing because of network conditions), identifying things which started to install but didn't complete, etc. This becomes difficult to deal with when you build packages that are hierarchical due to chocs current implementation details.

Some of these problems are discussed here:https://github.com/chocolatey/chocolatey/issues/253

So yes, there are some shortcoming, but even with these warts, it's still a fantastic tool, and I invest spare time in building packages to expand the ecosystem, etc. Also, I think you can see there's a trend here in the tracker -- big issues identified, solutions proposed, but nothing really implemented. I know that all of these problems can be solved and the system can be polished up quite a bit, it's simply a matter of time. This is one of those cases where it would be nice for a corp sponsor to push the state of the art forward, like Google does with a number of it's OSS projects. This is an area of Windows that is in sore need of better tooling, and I know Chocolatey could be really fantastic if collectively there were more cycles to push it forward.

I was super excited when I first discovered Chocolatey a few months ago. I created a simple PowerShell script to pull down all of my apps. I was stoked to see that the gallery had so many apps that I always install right away after formatting my PC.My one gripe with Chocolatey is that updating the packages is up to package owner to do (for security/reliability purposes I'm sure), and many of them don't update it regularly. So after installing everything using chocolatey I noticed that most of my apps were not on the latest version, so I ended up having to go to the app website anyways and manually download the latest version. Of course I also emailed the package owners asking them to update their packages. I guess this isn't as big of an issue for self-updating software, but a lot of software still doesn't self update and I always like to be on the latest stable version of an app. Many packages haven't been updated in a year or more.

They can't do it all. Each package needs a maintainer, which typically should be someone at the company themselves for the big packages and a superfan for the smaller ones.

Again, this is another symptom of the problem that makes them think it's OK to have unprofessional messages.

PRMan

Tuesday, 28 May 2013 17:30:34 UTC

I agree the name has to go. It sounds so uncerious that it is hard to recommend it in professional circumstances

Staffan Gustafsson

Tuesday, 28 May 2013 17:34:16 UTC

Scott - the link behind the main image of this post points to http://www.chocolately.org/ which is invalid. (note the extra L in the url)

Aaron King

Tuesday, 28 May 2013 18:26:58 UTC

I'm a big fan of chocolatey as a concept, but sadly I don't use it all that often. My biggest gripe is what Daniel Schroeder mentions, lack of package updates. I also usually end up going to the app's website because it's very often more recent than the chocolatey package. I guess this isn't helped by the fact that a large number of the packages on the chocolatey gallery are created and owned by other people (e.g. ferventcoder) on behalf of the app owners so the dependency is all on them to do the updates.

However, if chocolatey became more mainstream and recognised as a *primary* way to distribute an app, this would all change. App owners would feel compelled to make a chocolatey push part of their standard release process. I guess some handover/sharing of ownership of packages would be required to make this happen.

I am surprised no one has mentioned http://allmyapps.com/ I started using it a few years ago before they started charging for some of the features. Its a GUI equivalent somewhat like Ninite but with lots more apps.

You can browse a huge catalog of apps and make your own list to quickly get what you want installed. Some will install without GUI and some need to run through an installer but it saves time remembering everything you want to install and going to each site for latest version.... When new versions are released you get notified and can update easily.

Pete

Tuesday, 28 May 2013 19:05:37 UTC

If the name is such an issue could you not just alias out the commands in powershell or am I missing something?Do love the idea though used it recently to install what I needed on a clean box, though found myself googling the package names. Really need some search or list functionality.

I've never been a fan of "repackagers". IMHO, leave it to the tool maker for installation options. The core OS (and .NET framework) has some great options (that could potentially be improved) such as powershell, various MSI package tools, MSBuild/MSDeploy, vsix packagers, etc. If the curator wants to publish handy powershell installs then great. But I want to use powershell or a trusted setup executable for the installation published by the author (who has credibility and an expert reputation that I chose to trust).

I sometimes do browse ZDNET downloads or similar to see what is popular. I do remember when they started pushing the browser toolbar "spyware" and various virus scanners and it did "sneak up" on a lot of people. Since then, I typically go to the official web site to download and install from. I will likely do the same for Chocolatey.

I do love the idea of curators who take pride in showing the best of the best in utilities, tools and frameworks and sharing with the community. I like the "app store" or blog presentation for that. Sure if there is a common web API that publishers can elect to use, I might automate my own environment configuration but I expect the source to come from where the author elects, not the curator. Realistically how often do you really need to build out your entire environment?

Where the idea of a package manager does resonate for me is in the area where we already have one (nuget). That is "stacks" of toolkits and frameworks that work together nicely for application development. Here the dependencies are more difficult to track and it is often hard to get everything to work together unless you are working with known compatible kits and versions. Plus, the spirit of the effort is to reuse and not re-invent. Therefore a package manger is essential in that scenario.

I think we will find that the authors of tools will be against a single curator "injecting" itself into the process we know today. Developers spend countless hours putting everything together for our consumption and they at least deserve the ad revenue (and just general respect) that comes from visiting their site.

Yes Rik, you're missing something. :-) The naming issue isn't about communicating with the computer (aliasing out the commands), but communicating with other human beings. When a clueless manager dismisses your recommendation to use the non-enterprisey "Chocolately" [sic], it does little good to tell them "but I call it enterprisey-get on my own machine!"

I really like the concept and I use it quite a bit. However, I don't think it can ever be the trusted source with out involvement from Microsoft.

Ideally the Windows team would sanction some sort of install package format for desktop apps and utilities in the same way they have from store apps. That format could either be a native installer for apps or simply a wrapper around MSI to enable faster up take. With that in place you would need a repository hosted by Microsoft and requiring things like digital signatures, automated virus scan and smart screen.

Chris Patterson

Tuesday, 28 May 2013 21:16:57 UTC

Love the idea, love the name, love the unprofessional messages. I look forward to a future when I can ask people 'have you got chocolatey?'

And then you get slapped for your troubles.[Apologies for the lackluster HTML, still getting used to this]

Mathias

Tuesday, 28 May 2013 21:42:24 UTC

Sounds like Windows store. Only without GUI

itay

Tuesday, 28 May 2013 21:46:58 UTC

@Daniel Schroeder and Adam Ralph

Yes, this is an issue, and if like some people, you start having a number of Chocolatey Packages, maintaining them becomes hard. However, it should be pointed out that most package maintainers publicize their GitHub repos, so there is nothing to stop other community members submitting a pull request to get the package updated. Hope people would welcome the help.

Also, the other thing to think about is using Rob's Automatic Package updating tool:

https://github.com/chocolatey/chocolatey/wiki/AutomaticPackages

Which if implemented, allows the automatic updating and deployable of Chocolatey Packages.

But I agree, getting the application owners to make and deploy the chocolatey package as part of their release process is the best idea. That is what I have been trying to get OSS projects to do lately, pulling in the use of MyGet to temporarily deploy the Chocolatey Package for testing purposes, and then push to Chocolatey.

To all talking about adoption rate and enterprise use, chocolatey is not trying to compete in either of these areas yet, so it's fine if something as simple as the name is what is keeping it out. It's young and has rough edges and until some of those are smoothed out, I'm not sure we'd consider a rename.

@Doug - I think maybe you missed what Choco actually does. It is using what is already out there in the form of MSI/native installers from the author's site.

Chocolatey doesn't "inject" itself into the process you know today, it automates the process that you know today. It goes out to the author's site and downloads the installer, then silently installs it on your machine.

But I freely admit that choco is not for everyone. And we're fine with that...

While I can find no survey, based on a large population, which specifically states what percentage of Windows users even touch PowerShell, I'd guess the percentage of those who are willing to use a command-line driven "anything" is very low.

Chocolatey is clearly for geeks; I don't see any rationale for using gender, or being a parent, as a discriminating factor among the "technoid" Windows' user population: "Gender Non-Specific Non-Technical Parent," which is indirectly asserted by the double-negative format of your statement: "Chocolatey is clearly not meant ..."

Using command-line tools, in the age of GUI, is a reversion equivalent to throwing away bronze-swords, and going back to edges-flaked-by-hand stone adzes, and spear-tips.

That such tools as Chocolatey should be necessary is an indictment of the modern Windows OS (not that Apple's OS's are any better, or Linux, etc.).

A modern OS should provide a high-level interface to facilitate the secure downloading, installation, and updating of 3rd. party applications. To say that "should" be the case is not to imply that it is technically "simple," or "easy," in an age in which vast minions daily assault the security of OS's and applications, and browsers, to do so !

As a quondam geek, I do appreciate the hard work, creativity, and generosity, of people who create products like Chocolatey !

By the way, I find the name no "weirder" than any other software's name, but I would have preferred "Chocolately" (much more mnemonic, and equally nonsensical).

thanks, Bill

BillWoo

Wednesday, 29 May 2013 09:10:56 UTC

IMHO name is ok. apt-get is nowere better (try to find command to search packages). Chocolatey analog on Mac has name that I cannot even Google.

The only thing I do not really like with Chocolatey is verbosity. It too verbose.

Everything else is very nice. I do almost all installs with it. Especially on VMs where most of the time I use PowerShell remoting and Chocolatey works as a charm(if package does not show UI :) )

Contribution of Chocolatey packages are easy. If something is outdated, it is easy to contact package owners.

One thing Chocolatey is great for is setting up dependencies on your build server or target environments for continuous delivery.

I have an open source project powerdelivery that lets you use Team Foundation Server (or local) builds targeting your dev, test, production etc. environment with one script to do automated deployments in PowerShell. Chocolatey is built in, in that if you have a packages.config file next to your build script, any packages get installed on the TFS agent automatically.

You can also run Chocolatey with remote powershell commands on your target computers. It really does simplify deployment when you have a base OS image in a data center that you want to configure from the ground up to allow rapid standing up of new environments. Building packages is really easy (considering how complicated MSI can be) and Rob's team does a great job tweeting out updated packages as they are uploaded.

"Using command-line tools, in the age of GUI, is a reversion equivalent to throwing away bronze-swords, and going back to edges-flaked-by-hand stone adzes, and spear-tips."

BillWoo, where I find this not to be true is when you have Enterprise organizations that waste significant capital performing activities through the GUI and making mistakes. This is where automation and scripting are crucial to creating repeatable deployment processes and command-line tools are just a natural fit here.

This is just my opinion, but resonates well with operations personnel who have to feel comfortable with what teams are introducing into their production environment. I'm having success with getting ops people to actually start writing powershell deployment scripts (that call command-line tools like Chocolatey) as part of a SCRUM team's sprint deliverables. This way they aren't as paranoid when you're about to do a release as they helped write the automation and test deployment in a separate environment that will be repeated in production if builds are of suitable quality to release.

You really only run into these things when companies are doing frequent releases with many interconnected applications.

Other than the horribly naming, the main issue I have with chocolatey is the up-to-dateness. It's *not* a central repository or even close to widespread, so vendors and project maintainers don't update it.

Say I used cinst to install TFS sidekicks a long time ago (say a year and a half ago). I got version 2.4. Over the past year, chocolatey update *never* updated me. Most likely, I continue blissfully unaware that I'm outdated.

Or, I can go check the TFSSidekicks page myself and find that I can download 4.1, but then I'm stuck, how do I install it?

uninstall from chocolatey, then manually install it. once the choc feed is updated, reverse the process.

fork the choc feed repository, figure out how to maintain the package myself, update the choc nuget package, and send a pull request. Then wait for it to be accepted and use choc to update.

Do the same as #2, but instead of waiting create my own nuget feed with the fork that has my updates.

Bleh! In any case, I need manually watch and update my installs, still having to check the publisher's websites myself, and adding more steps regardless.

Now, this isn't a chocolatey volunteer's fault - until all the publishers update the packages or notify of updates it would take a person checking every package every day to fix this issue, and publishers aren't really going to help until a lot of their users are on it already. But why adopt it if it just adds work?

Also, the name is horrible.

Philip

Wednesday, 29 May 2013 19:16:16 UTC

Philip,

You bring up a good point. The way Linux distros handle this is there is a service that periodically runs the package manager to check for new packages and shows a tray icon letting you know there are available updates. You can then choose to install them. You can also choose to automatically install updated packages much like Windows update.

It wouldn't be too difficult to build an equivalent service that asks Chocolatey if there are updates to your installed packages.

A former co-worker of mine talked about this briefly while I worked with him. I never really dove in to it to understand what his excitement was about but now I get it.

However, after installing Chocolatey, I tried to install a few packages from the command line and it's constantly failing:

C:\Chocolatey\bin>cinst notepadplusplusChocolatey (v0.9.8.20) is installing notepadplusplus and dependencies. By installing you accept the license for notepadplusplus and each dependency you are installing.The schema version of 'Reuse' is incompatible with version 2.1.31022.9038 of NuGet. Please upgrade NuGet to the latest version from http://go.microsoft.com/fwlink/?LinkId=213942.

Scott - Thanks for the reply, that explains it! I neglected to check when windows-get had last been updated, that was the "something" I was missing in my original post. I'll definitely be trying Chocolatey. Can't wait for the release that removes all the cruft from the installers in the same fashion as Ninite.

@Brandon - I think you might have a package in your local nuget cache named "Reuse." You can clear the nuget cache in visual studio or you can go to %LocalAppData%\Nuget\Cache (don't quote me on that path though) and clear out the packages.

Upon looking further I see nuget.org has a package named Reuse (open browser insert nuget.org/packages/Reuse).

@Brandon - I found the issue. It has to do with a bug in nuget.exe. If you install things with an older version of nuget without specifying a source (after caching a package with v2.5 minimum version required), it gives you a warning and installs items successfully. UNLESS, and this is big, UNLESS you specify the -source parameter.

Then it fails every time. Logged an issue here. nuget.codeplex.com/discussions/445455

One cool feature I love about chocolatey is that you can install a group of tools using a packages.config file. It's a slightly modified version of the packages.config file used by nuget in .NET projects (added source attribute I believe).

This allows you to provide others on your team with a chocolatey packages.config file to install everything they need to develop on a project, including things like iisexpress, vs express / sharpdevelop, git, and so on. All the tools they might need.

You could even commit it to your source control, and put the info in your README so that they know what to do with it.

@Rob, I don't have issue with it as it is, but I think you could add a "build powershell script" feature that would allow one to select all fo the things to install and then it would export a script that the user could run. They could then key in their licenses as well. The script should only download if the files are not present in a zip library. Some similar techniques are used with psget.

Since 90% of windows software is commercial, I think an App store would be better. That way you could store the licenses. Free software could still be free, but you could have an e-commerce system like Amazon where a one-button purchase would encourage a little be of revenue for those who put there warez in your e-commerce system. Just a thought!

I like it so much, I even added two of my own packages after reading your blog post (both of which my packages seem to be getting some good download attention ;-), so i'm glad I've provided useful packages! Also decided to re-installed my Windows 8 on my PC and Laptop and installed all my favorite programs and tools using Chocolatey. Set myself up a Virtual Machine running my old Windows 7 OS key I had laying around previously and will now use this for future Package testing!

I see a good future ahead for Chocolatey, I agree with your security concerns, as I have already made a post about this on their group, as have many others, good thing is, they are taking this into consideration so i'm sure as it matures and more people use it, the 'people' will speak and ensure it becomes as secure as they can make it.

Keep up your awesome posts shanselhansllhamanman.

Also like to say I went through your kickstart course on Microsoft Virtual Academy, really enjoyed that so thanks!

Patrick Magee

Monday, 03 June 2013 15:57:12 UTC

I try now to implement signalR with MVC 3.Do you have an experience to take it together.I would like to use [Authorize] build-in MVC 3 with ChatHub.By the way, do you have a video about IIS ?

I love your explanations are clear and focused.Scotti, You are my MVC Teacher, I was started from scratch !!!

Thanks a lot my friend

Amit

Tuesday, 02 July 2013 11:33:30 UTC

I've been using chocolaty ever since I found out about it last year. Awesome tool. As for branding I say winget. Its similar to nuget and also goes along with the same idea as aptget.

Mohan

Thursday, 12 September 2013 16:59:08 UTC

I started using Chocolatey a few months back and despite my strong dislike of the root install I thought it was great - especially for command line users like myself. But now I've used it for a bit I realise there is one feature seriously lacking - so lacking in fact that I haven't used it for a few weeks now: package search. The clist command does a pretty limited job and is nowhere near the node package manager (npm) search. I can rarely remember the exact name but if I go onto the Chocolatey website with a couple of search words I find what I want straight away. But since I'm on the web and away from the command line, what's the point? I found this blog post as I just did a quick google to see if Chocolatey had done anything to rectify this but it appears not. Until this is addressed I won't be using it, which is a shame as it would be invaluable otherwise.

Matthew Blott

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.