Or ... is the OP wondering about "attaching to a process?" Original Poster: have you "attached to process" on your local machine, or have you always "started with debug" to test locally?
∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera) On Fri, Sep 4, 2009 at 7:04 AM, Andrew Badera<[email protected]> wrote: > When someone says "live" I equate that to "production." Staging isn't > live. It's not mission critical. "Live" is user-facing and activated > and in-use and possibly enterprise-driving. > > Remote debugging can be a pain. Usually is. But if you've got the > remote debug components in place and you can attach to the process, as > the OP indicated, it's just like debugging locally. If the "live" > server doesn't have .pdb symbol files, which a production server > shouldn't, I believe you should be able to reference the .pdbs in the > build directory that matches the set of assemblies on the server. > > ∞ Andy Badera > ∞ +1 518-641-1280 > ∞ This email is: [ ] bloggable [x] ask first [ ] private > ∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera) > > > > On Fri, Sep 4, 2009 at 6:59 AM, Cerebrus<[email protected]> wrote: >> >> That may be so, Andrew, but there are various types of remote servers >> - Staging servers, Test servers, Development servers etc. Remote >> Debugging on such a server is a useful trick. I happen to have tried >> it once earlier and was unsuccesful, just like the OP. So, I'm very >> interested to know the answer to this one. >> >> >> On Sep 3, 9:49 pm, Andrew Badera <[email protected]> wrote: >>> >>> Short answer: you don't. Most people in their right minds wouldn't >>> attach to a live process for debug. >>> >>> Long answer: you should be building flexible logging and tracing into >>> your code for these scenarios. log4net and the Enterprise Library >>> Exception Handling Application Block (EHAB) and Logging Application >>> Block (LAB) work well for this. You can turn tracing off or on from >>> the config file, so you wrap all operations in a trace. When you turn >>> it on, you get a trace log of all activities, so you know where >>> processing was at when an error occurred. >>> >>> Use exception handling and tunable-logging to send more or less, >>> richer or poor, details to the log. Again, this stuff is set in the >>> config file. You see problems, you turn it on. Problems solved? Turn >>> it off. >>> >>> ∞ Andy Badera >>> ∞ +1 518-641-1280 >>> ∞ This email is: [ ] bloggable [x] ask first [ ] private >>> ∞ Google >>> me:http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera)- Hide >>> quoted text - >>> >>> - Show quoted text - >> >
