http://bugs.winehq.org/show_bug.cgi?id=22870
Helder 'Lthere' Magalhães helder.magalhaes@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |helder.magalhaes@gmail.com
--- Comment #4 from Helder 'Lthere' Magalhães helder.magalhaes@gmail.com --- I've run msvcmon.exe with success, although it's a quite older version (Visual Studio .NET, a.k.a. 2002).
The command-line used is: msvcmon.exe -anyuser -maxsessions 1
Note that the 'anyyuser' is insecure, although it helps working around authentications in Wine+Linux (and even in Windows when domain controllers versus stand-alone machines are involved); the 'maxsessions' is only to make sure no one else gets in, as security is already lowered quite a bit.
Regarding comment 0: [...] the monitor will start and can connect with Visual Studio's debugger, but it will not start the target program to debug [...]
Actually, programs are not being started from within Visual Studio; instead, the debugger is attached once they are already running. If that was the case, try using that variation.
When debugging an application's start-up, one may use the quick+dirty trick of adding an ASSERT(FALSE) or similar to the very beginning of the application. That will trigger a "crash" dialog, which buys enough time to attach the debugger. Some experiments showed that pressing 'Retry' sometimes doesn't behave as expected (breaking into the debugger) and a "real" crash is triggered instead - press 'Ignore' for these fake assertions.