How to get package install directory from PowerShell steps

Hi there,

Which environment variable do I use to get the install path? I’ve tried concatenating the environment name and release number but that doesn’t always work e.g C:\Octopus\Applications\Integration\MyApp\1.0.0_1 can happen when the release number is 1.0.1

I need to know this because I’ve got a series of powershell scripts that need to be run in order, and in separate powershell processes (because of PowerShell GAC snapshotting at startup, for SharePoint you’ve got to separate out steps into different PowerShell processes otherwise it can’t find new assemblies from the WSP packages…).


You can use the variable:


From PowerShell it is:


Hope that helps,


This property has no value in my case (PowerShell step)

Hi Szymon,

At the moment variables don’t flow between package steps and script steps. Imagine you had a package step that was deployed to three machines, and then a script step. Each machine might put the package in a different place, so what variable would go to the script? It’s something we plan to find a solution for but the solution isn’t obvious.

Instead, the best approach at the moment would be to install the package to a known place (use the Custom Installation Directory feature in you package step). Then have your PowerShell script step use that same directory.

If you want to change the package location for each release, one option might be to set the custom installation directory like this:


That way your Package and Script step can both assume the same path.

Hope that helps,


Thnaks for such a quick answer. I’ve switched from using custom task to
post deploy script and it works great:)

Hi Paul, we have run into the exact same problem here, where we cannot get the directory that Octopus has deployed to in the PowerShell step. The octopus property you mentioned is blank in the PowerShell step.

In the example that you mention - 3 machines, with 3 different package locations - I would have thought that the octopus environment variables would all update according to the environment they are running in; so CustomInstallationDirectory would point to the current installation for the current environment. However by the sounds of it, its easier said than done!

Updating the documentation around the use of the environment variables in the powershell steps might be helpful for others in future.

Anyhow, as a workaround - we have followed the octopus convention to put a Deploy.ps1 in the root directory. This means octopus will call the Deploy.ps1 file - so once we are in the install location, we can then navigate to the other directories and call other ps1 scripts from there. So it just means we have put our powershell scripts into ps1 files in the deployment files instead of having them in a octopus PowerShell step.

Hi Terrence, thanks for the feedback. We’re also adding a feature to 2.2 that will let you run PowerShell scripts inside of the package step but without embedding them in your package (giving you access to all the same variables). You can see some screenshots here:


Thank you for this post a lot!
I was able to set the following value in the Custom install directory…

E:\Web#{Octopus.Project.Name}#{Octopus.Action[Deploy WebUI].Package.NuGetPackageVersion}


used $OctopusParameters[‘Octopus.Action[Deploy WebUI].Package.CustomInstallationDirectory’]

in my powershell script to associate it with the virtual directory and everything works together like a charm :-).


The only issue you would have Mani is if you had to deploy the same package multiple times. Currently OD will generate a version_# folder if you are forcing the deployment of a package which has already been deployed. Just something to think about.

I do think there should be some way to get the current package install directory in the powershell script. Maybe even if OD just kept the last install directory it used would be good to.

Thanks Matthew - we’ve added this in 2.4, you’ll be able to use a series of variables like:

Octopus.Action[My Website].Output.Package.InstallationDirectoryPath


Thanks so much for your response Matthew!

Strangely I haven’t had the “version_#” issue on my side. I did check the “Purge this directory before installation” checkbox. So redeploy clears out the Custom Installation directory before unpacking the nuget package. The NuGetPackageVersion is something I generate via a TFS build using OctoPack before it gets to OD.


It seems that if you set a custom install folder and then wants to access the folder where the NuGet package is initially being extracted BEFORE copied to the custom install folder, there is no variable that you can use for this in the CustomScriptConvention.PreDeploy.ps1 (Pre-deployment script) step.

$OctopusParameters[‘Octopus.Action[X].Package.CustomInstallationDirectory’] is set ok but $OctopusParameters[‘Octopus.Action[X].Output.Package.InstallationDirectoryPath’] is NULL and there is no parameter that holds the folder path to where the files are before being moved.

All I’m trying to do is to rename a file in the pre-deployment script step.

Any ideas?


Hi Mikael,

You can use $OctopusParameters["OctopusOriginalPackageDirectoryPath"] for this - it will tell you the path that Tentacle extracted the package to (the temporary folder before it copies). Hope that helps!


Thanks Paul, that worked!


I’m using File System Clean Directory script template in Octo Library on Github:

I provide Paths to clean variable to be: #{Octopus.Action[Cleanupconfigfiles].Output.Package.InstallationDirectoryPath}

The build log shows this error:
Paths To Clean: Octopus.Action[Cleanupconfigfiles].Output.Package.InstallationDirectoryPath
Info 19:04:49
WARNING: Could not locate path
Info 19:04:49

I need to delete web.*.config in website root directory and some files in /configuration directory in web site root directory.

Screen shot attached which show my child step variables.

Please let me know how to provide InstallationDirectoryPath in the Octo web UI?


Hi Sampat,

Thanks for getting in touch!

It looks like you have the incorrect step name in the Action - I believe it should be the previous step’s name.
Also the list of file names should be separated by a semicolon and not a comma.

See if that helps, and let me know how you get on.


Hi Vanessa,

Thanks for your inputs:

  1. Yes, I had to use previous child step name.
  2. I replaced comma with semicolon and the files are deleted as expected.


Hi - so I’m missing something.

Above you say this will get the value in PowerShell:


But then you say variables won’t flow between package steps and PowerShell. I don’t understand. If it doesn’t work in PowerShell why do you show how to access it in PowerShell? Why would someone ever want to access this value in PowerShell if it’s always null?

Hi Jon,

Thanks for getting in touch! It looks like you have jumped on to the end of an old discussion here.
You can grab variables from any package step and use it in a powershell step later.
Maybe have a look at this blog post to get started:

Hope this helps!