If they tell you the machines will outsmart us very soon, don’t believe it. Here’s why.
Tonight I was trying to add “Unity” dependency injection framework to my .NET 4 project under Visual Studio 2010 via NuGet. Yes, I know, stone axes are no longer supported, but whatever.
Here are the list of steps, just for my record, and perhaps for someone’s sadistic geeky amusement, if they are into that kind of stuff. So,
- Opened Tools->Library Package Manager->Manage NuGet Packages for Solution. Typed “Unity” in the search box. It came out first.
- Clicked on “Install”. Was told that this version of Unity requires .NET 4.5 which none of my projects supports (duh!).
- Searched for a button or menu to list older versions – did not find any.
- Googled how to install older version with NuGet – did not find any encouraging results. But found NuGet PowerShell reference instead.
Get-Package -ListAvailable -Filter Unity in Powershell. Got 40 results, in alphabetical order, none of them is Unity. Tried
-Skip options: no can do, a subset of the same 40 results.
- Googled it. Found something about a bug in NuGet that is fixed in the new version.
- Went to update NuGet to version 2.5 via Visual Studio Extension Manager. Installation failed, complaining something about the signature of my current NuGet not matching what they expect. Well, it did not complain per se, it just stated the failure, and gave the link to an installation log. The message with the actual root cause was in the middle of a very long line towards the end of file, around column 200, so some serious horizontal scrolling was required.
- Went to uninstall current NuGet in the Extension Manager. Install button is disabled.
- Googled it. Re-ran Visual Studio as administrator. Uninstalled current Nu-Get.
- Installed NuGet 2.5. First small victory!
Get-Package -ListAvailable -Filter Unity in Powershell. It returned over a hundred packages, Unity came 96th. But this displays only the latest version, and I wanted the previous one.
- Tried to find the way to limit the search, so it would return just
Unity. No cigar. According to the documentation
-Filter searches in “package Id, the description and tags”. Trying to specify “The Unity Application Block” as a filter does not do any good: even more packages are returned. But
-Skip 96 - First 1 gives me only Unity. OK so far.
Get-Package -ListAvailable -Filter Unity -AllVersions -Skip 96 -First 1. It waits a while (10 seconds or so), and then gives me
Cavity.ServiceLocation.Unit... 18.104.22.1687. Well, apparently it skips lines, not packages. Argh.
- Googled it. No cigar. Found a reference to another command line, the nuget.exe tool.
- Downloaded nuget.exe. It refused to run, requesting that I set some environment variable. Well, I did. It ran.
nuget list unity. Get a hundred packages again.
nuget list Unity -allversions and redirected output to a file. It took several minutes to create the file, and it came out with 1525 lines of text.
- Found that the previous version of Unity is (ta-da) 2.1.505.2. It’s right there, in front of your eyes, proudly sitting on line 1353.
- Back to Powershell,
Install-Package Unity -Version 2.1.505.2.
Victory at last!
Some points to raise with the NuGet team(s):
- A search by Package Id only would be nice; an exact search by Id would be even nicer
- Why is it that when I search for Unity in Gallery it comes up first, and not 96th? Do they have a different API? If yes, why isn’t it available via Powershell or command line?
- Installing previous version of a package should not require a degree in forensic science; having a menu listing all versions would save me 1.5 hours of work and lots of nerve cells.