Thanks for getting in touch. I'm very sorry your file got into
such state. We haven't heard other reports of this behavior, so
we'll be very interested in getting all the information possible to
try to reproduce it and come up with a fix.
Could you start by sending us the log of the deployment that
broke the config file?
Yes we can try to investigate what happen, at least now when
everything operates normal I will be glad to give you any
Just need to clean up some data from logs which may be sensitive
(or is there a way to send you logs directly?)
From audit logs I do see following:
there was failed deploy in 11:20
in error logs for it I do see
Running: Upload package migrator version 1.0.141-master
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
System.IO.FileLoadException: Could not load file or assembly 'NuGet.Core, Version=188.8.131.522, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Provider DLL failed to initialize correctly. (Exception from HRESULT: 0x8009001D)
then in ten minutes there is successful deploy of same project /
then in ten more minutes failed deploy of new version where
in logs it says that it were broken right after trying to set
basic authentication enabled to false which may not be related to
11:41:28 Info | Comparing existing IIS bindings with configured bindings...
11:41:28 Info | Looks OK
11:41:28 Info | Bindings are as configured. No changes required.
11:41:28 Info | Anonymous authentication enabled: True
11:41:28 Info | Applied configuration changes to section "system.webServer/security/authentication/anonymousAuthentication" for "MACHINE/WEBROOT/APPHOST/Rabota.ua2 Mobile" at configuration commit path "MACHINE/WEBROOT/APPHOST"
11:41:28 Info | Basic authentication enabled: False
11:41:28 Info | ERROR ( message:Configuration error
11:41:28 Info | Filename: \\?\C:\Windows\system32\inetsrv\config\applicationHost.config
11:41:28 Info | Line Number: 1563
11:41:28 Info | Description: Configuration file is not well-formed XML
11:41:28 Info | . )
That xml is shipped with dlls, I have checked its nuget
install.ps1 and there is nothig special with it, also nuget
packages are shipped inside packages already preinstalled so should
no do anything to them
Also looking at your code I definitely may say that it also wont
do anything like that
So by logs it seems that octopus were able to verify all
bindings which makes me thinking that in that point of time
applicationHost.config were ok
I sent logs, packages, description to email with subject
"Detailed logs for applicationHost.config destroyed [Problems
Hope it will help in investigation
In meanwhile will not touch anything in case we will need to try
reproduce this (thank to gods it was stagin server so if there will
be need theoretically I can try reprpoduce it and collect some more
Thanks for giving us all those details, we had a discussion and
some thought about this.
A popular feature: 'parallel deploys' makes trying to roll back
changes to the 'applicationHost.config' not possible, as it would
break the behavior for those customers, so we won't be trying to
introduce a way to recover such files automatically.
What you can do in your case to give you more confidence is
introduce 2 extra scripted steps; first one being a pre-deploy step
to back up that file (and any others). Followed by a deploy-failure
step (you run only if needed) to revert those files if it does
fail. You could also give the Guided Failures feature a try to give
you extra safety: https://octopus.com/docs/deploying-applications/guided-failures
As for the issue of the file itself becoming corrupted; we had a
look and with the details you supplied cannot work out went wrong.
Please let us know if you experience it again and hopefully
additional information might help pinpoint the problem.