Here is a list of PowerShell examples taken right from the packages you might already be using, some have more detailed explanation or examples elsewhere on the web. This list intends to be a quick reference for common operations when building install scripts for your NuGet packages. Keep the list handy for writing install for your own packages.
Read Properties from Visual Studio Objects
from SqlServerCompact
$currentPostBuildCmd = $project.Properties.Item("PostBuildEvent").Value
This gets the post build command from the specified project item.
Loop Through All Installed Packages
from NuGetPackageUpdater
foreach ($package in get-package) {
write-host "Package $($package.Id) is installed"
}
This loops through all packages that are installed on the currently targeted project.
Loop Through All Projects in the Solution
from NuGetPackageUpdater
foreach ($proj in get-project) {
write-host "Project $($proj.Name) is in this solution."
}
This outputs the name of each project in the solution in the package manager console.
Delete an Item in a Project
from MvcScaffolding
Get-ProjectItem "foo.txt" | %{ $_.Delete() } or
Get-ProjectItem "InstallationDummyFile.txt" -Project $projectName | %{ $_.Delete() }
This gets the specified file from the current project and 'pipes' it into the next command, which is a call to delete. The "$_" is a token representing the passed-in object. If you have the name of the project and want to target that project, you can also use the -Project argument as in the second example.
Remove a Reference from a Project
from Machine.Specifications
$project.Object.References | Where-Object
{ $_.Name -eq 'NameOfReference' } | ForEach-Object { $_.Remove() }
If you're looking to purge references that you know are safe to do so when you're uninstalling, you can do so as above. This uses a filter to selectively remove a reference from the project in question. You could also use a foreach at the project level and remove the reference from each project (rather than using the $project param that NuGet feeds you when uninstall is executed).
Alternatively, rather than assuming your user hasn't taken on the dependency in another fashion in their project, you could simply use Write-Host and let them know that if they aren't using the references you've added (during your install), that it is now safe to remove them from the project in question.
Loop Through All Project Items
from MisterJames
ForEach ($item in $project.ProjectItems) { Write-Host $item.Name }
This will print out the list of all items in the specified project. You can use $item for project item operations per the VS automation docs (see link at bottom), here, I've just output the name.
Open a File from the Tools Folder
from EfCodeFirst (note that this is a legacy package no longer used)
$dte.ItemOperations.OpenFile($toolsPath + '\EFCodeFirstReadMe.txt')
This one is pretty straightforward. $toolsPath is passed into our script and is available as a parameter throughout. Here, we're simply calling $dte.ItemOperations.OpenFile to open the file specified.
Opening a File from the Content Folder
from Glimpse.Mvc3
$path = [System.IO.Path]
$readmefile = $path::Combine($path::GetDirectoryName($project.FileName),
"App_Readme\glimpse.mvc3.readme.txt")
$DTE.ExecuteCommand("File.OpenFile", $readmefile)
In this example, there are two variables at play, a System.IO.Path variable and a string being built to open a file. In the final line, $DTE.ExecuteCommand is called to invoke Visual Studio's "open file" command in a different way from EFCodeFirst, with the filename passed in as a parameter.
Calling Other Scripts in the Current Scope
from SqlServerCompact
(Join-Path $toolsPath "GetSqlCEPostBuildCmd.ps1")
PowerShell will execute the specified file in the context of the current script when you do a "dot-space-brackets". In this example, we need to concatenate the name of our script, which is located in the package tools directory, to the tools path and then make the call. At this point, any vars you set up will be available to you in the current script. If you want to break out and build a list of files or - in this case - set up a variable with post-build information, this is your vehicle.
Exploring On Your Own
If you want to accomplish something that you don’t see here but have seen in another package, it’s pretty easy to see what they’ve done. You need to get yourself a copy of the NuGet Package Explorer – also a great tool for building your own packages – and just start pulling down the work that’s out there.
The best part about using this for exploratory purposes is that it can connect directly to a repository feed. Just pull up File –> Open from Feed… to search or browse packages. The NuGet.org package repository load by default, but you can specify your own.
References
You can dive much deeper, of course, as you have PowerShell in your hands here, controlling the IDE. If you want more information on specifics of any of the ideas at play here, check out the following links:
Wrapping Up
Know any other good samples? A more straight-forward way to pull something off? Feel free to send me a note so I can add them here, or send questions my way.
CodeProject
