Octopus CLI issues on MacOS

(It) #1

Today all of a sudden I am having issues using octopus CLI tools on my Mac
I originally installed it using brew as per the install pages, but also tried downloading it manually but I get the same error.

When I run octo I get the following error

  An assembly specified in the application dependencies manifest (octo.deps.json) was not found:
    package: 'Markdig', version: '0.10.4'
    path: 'lib/netstandard1.1/Markdig.dll'

Does anyone know what the issue could be?
I am downloading and using version 7.3.4
And I am on MacOS 10.13.6

(Jeremy Miller) #3

Hi it2,

Welcome to the Octopus forums.

The issue you’re experiencing is one our engineers are currently actually already looking into. We will update you when we get a permanent solution. For now a workaround is to delete the folder where octo houses all of its dependencies. To find this folder run these commands.

cd /private/var/folders
find . -type d -name octo

You should see a folder inside of octo that has a bunch of dependencies. If you delete the octo folder itself, the next time you run the octo command the dependencies will get extracted again and be in working condition.

Please let me know if this works for you and we will update you going forward about a more permanent solution. Please reach out in the mean time if you have more questions.


(It) #4

Hi Jeremy

Thanks for getting back to me so fast.

Your steps worked exactly as you said, and after removing the octo directory, running the octo command again it is now working again.

Why exactly is this happening? It does seem to happen sporadically, last time it happened there was actually a version upgrade so upgrading fixed the problem.

I will rerun these steps next time it happens, at least there is a workaround as the CLI is so useful for my CI/CD pipelines


(Jeremy Miller) #5


You’re welcome! Glad to hear the workaround is working for you. Unfortunately our engineers are still currently investigating the root cause. Once we have identified the root cause and a permanent fix, we will update you. Please don’t hesitate to reach out in the mean time with any questions.


(Frank Lin) #6


I have some good news - this is an issue with dotnet and single file executables, and you can work around it.
​When you run octo, dotnet actually extracts the files inside the executable into a temporary location (often it goes under /private/var/folders/...) then runs it. I googled around and found some other people also experiencing a similar issue.
​Although we don’t know which process is going around deleting those files, you can change the location where the temporary files are extracted.
The .net documentation​ here explains how the extraction location is determined. You can override this by setting the DOTNET_BUNDLE_EXTRACT_BASE_DIR environment variable to somewhere else.


1 Like
(It) #7

Thanks Frank good to know that dotnet is the culprit.

I will keep your workaround in my tool chest too to pull out when I next need it.

I assume I can set DOTNET_BUNDLE_EXTRACT_BASE_DIR to where ever I like i.e.


I assume there will be a fix coming in a new release of octo cli?


(Frank Lin) #10

Hi @it2,

Yes you can set DOTNET_BUNDLE_EXTRACT_BASE_DIR to where ever you like.

Microsoft has fixed this bug recently (not yet released), so we will be able to fix this permanent once Microsoft releases the new version of NetCore 3.1.


(It) #11

Great news thanks Frank I look forward to the patching being released.

Thanks for updating me on the progress.

1 Like
(Matt Richardson) #18

Hi @it2
​Just a quick note to let you know that we’ve released version 7.3.7 of OctopusCLI which has been rebuilt using the latest version of .NET Core, and the issue has been resolved.
Happy deployments!

(It) #19

Hi Matt

Thanks for getting back to me on this and GREAT news about the new version with .NET core fix. I have just upgraded to 7.3.7 using brew so will let you know if I have any further issues.

Thanks again and great support +1