OctopusPackageDirectoryPath results in two extractions

We noticed today when we tried to set the $OctopusPackageDirectoryPath variable that when we deployed, the tentacle (0.9.620.4) extracted the package into the directory we specified, but it also extracted it into the default path of c:\Octopus\Tentacle\Applications\MyPackage.1.0.0.

Normally this would be a minor issue, but we are trying to use $OctopusPackageDirectoryPath when redeploying an IIS site to prevent IOExceptions from being thrown due to the problem described in this thread.

Since the trello card for using a new folder when force deploying got bumped to v1.1, we’d like to see a fix for this issue soon.

The problem is especially troubling because it bites us when we want to roll back a bad release. Roll back scenarios should be more reliable than they currently are.

Hi Chris,

The Tentacle will extract the package to C:\Octopus\Tentacle\Applications… before copying it to the $OctopusPackageDirectory (if specified). It shouldn’t point IIS to that directory so it shouldn’t really be causing any problems (except possibly, storage). What issue is it causing you?

I’ll reconsider pulling that card back into 1.0 tonight and I’ll definitely make sure that rollback is more reliable for 1.0.


The specific issue we ran into was as follows:

  1. Success deploy MyPackage.1.0
  2. Fail: deploy MyPackage 1.1

At this point we found that even though IIS was pointing to MyPackage.1.1, it still held a handle on MyPackage.1.0 that prevented the directory from being removed or accessed.

  1. Fail: deploy MyPackage.1.0

At this point we created a new release with $OctopusPackageDirectory set and deploy that, but it also fails because it still wants to use a directory that IIS won’t let go of.

Recycling the app pool ultimately resolved the problem. I’m not sure if this was a transient problem with IIS, but switching the site folder in IIS doesn’t always seem to completely release the old directory.

Ahh, that makes sense, thanks for the explanation Chris.

So in this case, the Trello card suggestion of creating a new folder sounds like it would fix the issue as you said.

However if you were still using the $OctopusPackageDirectory variable it would still fail, because IIS might be pointing to a file under $OctopusPackageDirectory. So I think the path going forward will be:

  1. If $OctopusPackageDirectory is set, stop IIS
  2. Perform deployment as normal
  3. Start IIS if it was stopped

A new directory will always be used under C:\Octopus\Applications… so that shouldn’t prevent a deployment from happening.

What this does mean is that if $OctopusPackageDirectory is specified (and in use), there will be an unavoidable IIS stop and some temporary downtime while the package is deployed. For most people it won’t be a problem but it will need to be documented.

What do you think about that proposal? How do you think it should work?


This is a tricky one. Stopping IIS before expanding the package would happen before PreDeploy.ps1 has a chance to tell the load balancer to stop sending traffic to us. That’s something we currently do.

If the package gets unzipped into Tentacle/Applications anyway, it seems like my shop would be better off simulating $OctopusPackageDirectory in our own powershell scripts so we can control the order of events:

  1. Disable LTM
  2. Stop IIS (or just this one virtual site)
  3. Move/copy files into place
  4. Start IIS
  5. Smoke tests
  6. Enable LTM

For all of our scenarios to work, we’d just need the trello story to be implemented.

Thanks for considering moving that story up in priority.


Thanks Chris, that makes sense. In this case I’ll leave the behaviour of OctopusPackageDirectory as it currently is (no automatic IIS resets), and I’ll implement that card. If you check Trello you’ll find I have brought it forward.


Just verified that this is working as expected in Octopus