We’re using the on-prem version of Octopus for releasing ASP.NET websites and have encountered a strange problem in the last months.
Sometimes (like 1 a out of 3) when the site startup after a release the old process still have locks on some files (ie a disk cache file that is used by Umbraco CMS), restarting the app pool manually solves this but it’s not something that we would like to do.
So I’m wondering if there is any way around this? Does octopus just change the path to the website during the release or does it in some way restart the app pool? If not, can this be configured?
Thanks for getting in touch!
The standard Deploy to IIS step doesn’t perform any special actions when deploying, it essentially just copies the files into place (and deletes the current ones if purge is selected), then configures the website if selected.
When I’ve encountered this before I had to add the IIS - AppPool Stop community steps to release the locks prior to the deployment step.
Thanks Paul! I’ll givet that a try!
How do you approach this, a restart after the deploy or do your first stop the app-pool, deploy the package and then start again?
The IIS Deploy step has the ability to start the App Pool, so, I just added the single stop app pool step, then let the IIS Deploy step start it back up again when it finished.
Thanks Paul! I’ll give that a try!
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.