There are two things at play here.
The framework has a debugging engine - this is part of the netmf firmware. You can’t influence it except by starving it from CPU cycles and using the debug calls it exposes.
The VS deployment tools and debugger utilise the debugging engine on the uC to do the deployment and then establish a debugging session. If you have your code open in VS and hit deploy&debug, the debugger wants to attach to the debugging engine and send it the code and then reset the device and reattach the debugger so you can do your debugging.
Consider the complete powered-down scenario. The framework goes through initial startup and then starts your application. If your app doesn’t release the processor (with thread.sleep) then when you come along some time later and attempt to attach the debugger to the debugging engine, it’ll try and eventually time out because the engine never gets the chance to respond. You should be able to show the same behaviour with mfdeploy and attaching the debugger there to the running device/code.
Consider the restarting hardware scenario if you manage to get deployment to work and it’s attempting to reattach the debugger after restart. Again, it’ll try and it will time out.
So here’s what I would do. If your app has no downtime and can’t have thread.sleep when it’s running, you have to adjust your debugging expectations. Add a wait at the start of the app (the 10 sec wait we added is fine, or have it wait for a button press), and then when you want to deploy a new version of your code, simply hit deploy and hit reset on your device; that means the debugging engine will get it’s chance to respond when it’s in the 10 sec wait, it’ll do a deployment and then restart the device again, wait again for 10 secs, debugger will attach and you can continue on your merry debugging way - but beware that your code may not let the debugging session actually do it’s thing.
If you want it to behave differently you’re likely going to need to relinquish the processor more often. thread.sleep(10) sprinkled thru your code. Then, you should find less issues when you are attempting to deploy new code irrespective of the state of the debugging session. But as a quick and simple workaround, a simple reset often does the business when you see attaching debugger iterations and timeouts…