Duplicati: Debug during customization

Created on 20 Mar 2018  路  5Comments  路  Source: duplicati/duplicati



  • [x] I have searched open and closed issues for duplicates.

Environment info


  • Duplicati version: 2.0.0.0
  • Operating system: Windows 10
  • Backend:

Description

I'd like to debug during backend customization. I added several breakpoints and I launched in Debug mode but wasn't able to debug some process.
Also, I tried to attach to the existing process, and it also won't work.
Could you please explain how you guys are debugging during development?

Most helpful comment

Sorry, I was meaning to just say that I'm pretty sure I've hit the same issue as you - running a tool in Debug mode from Visual Studio with breakpoints set didn't actually hit any of them.

I tried looking into why that was the case, and my best guess is that something with the auto-updater (which runs in the original Main() method, and then decides whether to run the RealMain() in the same process, a new process, or a new AppDomain) causes the actual logic to run in a process that Visual Studio isn't attached too.

Since I'm not very familiar with how the auto-updater makes that decision, I think having a command line flag (--no-auto-update maybe?) that ensures the logic is run in the initially started process would be useful.

All 5 comments

I've hit the same thing (and it seems like it has to do with the auto-updater launching either a new instance of the process or running the main code in a new AppDomain). I saw what looked like a few environment variables to toggle behavior one way or another, but I personally would prefer a command line flag that we can pass in to force running the main code in the initial process.

Sorry, but I didn't understand what you exactly mean by your comment

Sorry, I was meaning to just say that I'm pretty sure I've hit the same issue as you - running a tool in Debug mode from Visual Studio with breakpoints set didn't actually hit any of them.

I tried looking into why that was the case, and my best guess is that something with the auto-updater (which runs in the original Main() method, and then decides whether to run the RealMain() in the same process, a new process, or a new AppDomain) causes the actual logic to run in a process that Visual Studio isn't attached too.

Since I'm not very familiar with how the auto-updater makes that decision, I think having a command line flag (--no-auto-update maybe?) that ensures the logic is run in the initially started process would be useful.

Ok, thank you for your comment.

Was this page helpful?
0 / 5 - 0 ratings