Rob Erez on 12 Feb, 2018 10:35 PM
This change was a result of some updates made to support additional feeds where invalid filename characters are used in the packageIds. To facilitate those It was decided the most robust solution would be to encode the filenames to prevent any invalid characters getting used. This was calculated to be safer than trying to play a cat-and-mouse game finding and replacing characters on a case by case basis, and then dealing with issues of double encoding. Ill take a look at what can be done to preserve some of the "valid" characters which are getting transformed (in your case the +). This was added in a Breaking Changes section of the release notes https://octopus.com/downloads/compare?from=2018.1.5&to=2018.2.1. In the meantime so I can understand the issue better, what is the reason you rely on specific folder names rather than just using the Octopus.Action.Package.InstallationDirectoryPath variable to configure as needed?
There is no specific reason why we did not use the Octopus.Action.Package.InstallationDirectoryPath variable, but until now it wasn’t needed, and the default path was considered a good location to map the IIS virtual directory to.
The issue is that I don’t have an issue with the url-encodage itself, but IIS has. When we try to map a site to a folder with %2B in it, it breaks on us when trying to load the assemblies.
The exact error message from IIS-Events is:
Application Path: C:\Octopus\Applications\Dev\Api\2.0.0An unhandled exception has occurred.Bdev20180209.005\
In the meantime, do you have an ETA on the fix where the + sign will be preserved?
Rob Erez on 14 Feb, 2018 04:08 AM
It is certainly strange that IIS is so picky about the file naming. I am looking at rolling out a fix that will allow valid filesystem characters like + which will hopefully be available in the next few days. Ill let you know once it is out. In the meantime is it possible to remove the metadata or use a custom installation directory? I know its not ideal but if you need these releases to go out immediately that should be a workable workaround. Thanks again,
We have just fallen foul of this issue with IIS failing when the mapped folder has the %2b in it. We have just moved to a custom versioning convention for now but would like to move back to the SemVer + notation.
Rob Erez on 15 Feb, 2018 09:38 PM
As an update, a fix will be going out in the next release (2018.3.4) which will allow the + characters in the file paths. This may be an interim fix until we can implement a more robust solution to allow for future cases when we may have other feeds which have illegal characters and need to work against IIS.
Keep an eye out for this release in the next few days and let me know if you do (or don't) have any further problems.