Reply to thread

Message

remote debugging

there are some things you should be aware of.
You need to have the authentication set up and working between your debuggee (the targe machine running debug code) and your debugger.

This means in reality NO cross-domain stuff. If you have a domain-member debugger machine, you will at most be able to debug a debuggee in the same AD forest or a stand-alone machine, by creating a login with the same name and password on your debugger, and LOGGING in using that before starting the debugging session.

With winxp sp1 and earlier I have tried unsuccessfully to debug a debuggee in another non-trusted domain, and it does not work. Even if running msdev environment with runas command under another account. Visual studio still uses the logged in user as the authentication against the debuggee, which fails unless the user has debugging special rights or is an admins member on the debuggee machine.

While it is possible, I am not 100% comfortable with recommending it as it requires also similar versions of all the used (referenced) assemblies, libraris, and probably for directx stuff more than that as well. That is on both the debuggee and debugger.
(I have nada experience with directx, but can only imagine that it would require VERY similar versions of that as well, which can be really problematic considering all the directx versions and patches our there)

So there you have my less-than-2-cents. Personally I just usually set up a remote session to the desktop of the debuggee and debug locally. Or kind of locally with remote access. Damn that is so philosophical. Anyway you know what I mean. Maybe.

<blockquote data-quote="Myyz" data-source="post: 16065">remote debuggingthere are some things you should be aware of.You need to have the authentication set up and working between your debuggee (the targe machine running debug code) and your debugger.This means in reality NO cross-domain stuff. If you have a domain-member debugger machine, you will at most be able to debug a debuggee in the same AD forest or a stand-alone machine, by creating a login with the same name and password on your debugger, and LOGGING in using that before starting the debugging session.With winxp sp1 and earlier I have tried unsuccessfully to debug a debuggee in another non-trusted domain, and it does not work. Even if running msdev environment with runas command under another account. Visual studio still uses the logged in user as the authentication against the debuggee, which fails unless the user has debugging special rights or is an admins member on the debuggee machine.While it is possible, I am not 100% comfortable with recommending it as it requires also similar versions of all the used (referenced) assemblies, libraris, and probably for directx stuff more than that as well. That is on both the debuggee and debugger.(I have nada experience with directx, but can only imagine that it would require VERY similar versions of that as well, which can be really problematic considering all the directx versions and patches our there)So there you have my less-than-2-cents. Personally I just usually set up a remote session to the desktop of the debuggee and debug locally. Or kind&nbsp; of locally with remote access. Damn that is so philosophical. Anyway you know what I mean. Maybe.</blockquote>

[QUOTE="Myyz, post: 16065"] [b]remote debugging[/b] there are some things you should be aware of. You need to have the authentication set up and working between your debuggee (the targe machine running debug code) and your debugger. This means in reality NO cross-domain stuff. If you have a domain-member debugger machine, you will at most be able to debug a debuggee in the same AD forest or a stand-alone machine, by creating a login with the same name and password on your debugger, and LOGGING in using that before starting the debugging session. With winxp sp1 and earlier I have tried unsuccessfully to debug a debuggee in another non-trusted domain, and it does not work. Even if running msdev environment with runas command under another account. Visual studio still uses the logged in user as the authentication against the debuggee, which fails unless the user has debugging special rights or is an admins member on the debuggee machine. While it is possible, I am not 100% comfortable with recommending it as it requires also similar versions of all the used (referenced) assemblies, libraris, and probably for directx stuff more than that as well. That is on both the debuggee and debugger. (I have nada experience with directx, but can only imagine that it would require VERY similar versions of that as well, which can be really problematic considering all the directx versions and patches our there) So there you have my less-than-2-cents. Personally I just usually set up a remote session to the desktop of the debuggee and debug locally. Or kind of locally with remote access. Damn that is so philosophical. Anyway you know what I mean. Maybe. [/QUOTE]