I’m an Ubuntu guy so apt-get has my respect. It follows quickly that when Phil Haack and his crew come out with NuGet I’m ready. NuGet should take away one unusual annoyance I’m getting with the MVVM Light binaries installed “by hand”—I’m getting this type-or-namespace-GalaSoft-not-found error continually! I have to manually Add Reference… and rummage through the file system to refresh the Visual Studio project links the binaries. My optimistic assumption is that the NuGet packaging of MVVM Light will prevent this strange error and save me from rummaging.
After reading “Finding and Installing a NuGet Package Using the Package Manager Console” I used this:
PM> Get-Package -remote -filter MvvmLight
A PowerShell table formatted for the console should return one row with the MvvmLight package information—make sure that Package source: is set to All in the Package Manager Console. Running the Install-Package command will install the relevant MVVM Light binaries (for Silverlight or WPF) into the Visual Studio project selected in the Default project: combo box.
In my case I would have to run Install-Packagefour times like this:
Install-Package MvvmLight
Each time I would have to change project the Default project: combo box. Using the, er, power of PowerShell, these are the four projects I’m talking about:
PM> Get-Project -all | where {$_.Name -match "Songhay.Silverlight" -and $_.Name -notmatch "ApplicationLoader" -and $_.Name -notmatch ".Xml"} | format-table Name
Name ---- Songhay.Silverlight Songhay.Silverlight.Mvvm Songhay.Silverlight.BiggestBox.IndexPart Songhay.Silverlight.BiggestBox
So let’s make life a tad easier: let’s list all projects, filter this list and loop through the filtered output, running the Install-Package command:
PM> Get-Project -all | where {$_.Name -match "Songhay.Silverlight" -and $_.Name -notmatch "ApplicationLoader" -and $_.Name -notmatch ".Xml"} | ForEach-Object {Install-Package MvvmLight -project $_.Name}
