| Author |
 Topic  |
|
|
catesandrew
New Member
USA
2 Posts |
 Posted - Oct 19 2004 : 11:13:09 AM
|
| I'm currently using CodeRush from DevExpress and when I load it and Visual Assist X at the same time, my Dev Environment becomes unstable and crashes. Is Visual Assist X comptablie with coderush? If so, are there any special settings to get them to co-exist? |
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
|
|
catesandrew
New Member
USA
2 Posts |
Posted - Oct 19 2004 : 2:22:27 PM
|
| So the two can't co-exist, huh. It appeared that way to me as well. |
 |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Mar 03 2005 : 10:16:41 AM
|
No workaround.
The two add-ins use integration code in the IDE that is not multi-threaded. |
Edited by - support on Oct 22 2005 1:42:25 PM |
|
|
|
Mark Miller
New Member
2 Posts |
Posted - Oct 26 2005 : 4:33:08 PM
|
quote:
Originally posted by support
No workaround.
The two add-ins use integration code in the IDE that is not multi-threaded.
It is unlikely that this issue has anything to
do with the use of integration code that is not
thread-safe. VSIP code that isn't thread-safe
can only be called from the main UI thread,
and would be problematic if called from any
thread that was not the main UI thread. That's
true regardless of whether any other tools are
loaded or not.
The fact that the conflict exists seems to
indicate something else. FWIW, I sent the
following call stack to support last week
(not sure if it was received):
Unhandled exception at 0x791ef5d2 (mscorwks.dll) in devenv.exe: 0xC0000005:
Access violation reading location 0x029110fc.
This exception is thrown after CodeRush,
Refactor!, and the DXCore have been
unloaded (Disconnect call has occurred
and the method executes cleanly without
errors).
Here's the call stack (the Visual Assist
version is 1.4.18):
> 080376da()
user32.dll!_InternalCallWinProc@20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes
user32.dll!_CallWindowProcAorW@24() + 0x51 bytes
user32.dll!_CallWindowProcA@20() + 0x1b bytes
VA_X.dll!1ee5f844()
[Frames below may be incorrect and/or missing, no symbols loaded for
VA_X.dll]
VA_X.dll!1ee5fee0()
VA_X.dll!1ed0fdbf()
VA_X.dll!1ee5ee0d()
VA_X.dll!1ee84868()
VA_X.dll!1ee5f016()
user32.dll!_InternalCallWinProc@20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes
user32.dll!_DispatchClientMessage@20() + 0x4d bytes
user32.dll!___fnDWORD@4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13 bytes
user32.dll!_NtUserPeekMessage@20() + 0xc bytes
user32.dll!_PeekMessageA@20() + 0xfb bytes
msenv.dll!ThunderMsgLoop() + 0x5fa2a bytes
msenv.dll!CMsoCMHandler::FPushMessageLoop() + 0x1f bytes
MSO.DLL!SCM::FPushMessageLoop() + 0x92 bytes
MSO.DLL!SCM_MsoCompMgr::FPushMessageLoop() + 0x2b bytes
msenv.dll!CMsoComponent::PushMsgLoop() + 0x26 bytes
msenv.dll!_VStudioMain() + 0x137 bytes
devenv.exe!util_CallVsMain() + 0xb4 bytes
devenv.exe!CDevEnvAppId::Run() + 0x614 bytes
devenv.exe!_WinMain@16() + 0x4c bytes
devenv.exe!_WinMainCRTStartup() + 0x5f88 bytes
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes
Our devs think this may be related to subclassing the editor.
Interestingly enough, there appears to be a work-around....
In our tests, we were unable to
reproduce the problem if we
loaded the DXCore *after* VS
started (VAX is already loaded
by then).
To make this work, you'll need
to load DXCore manually after
starting VS, but this is pretty
easy to do.
Steps to try this work-around
are as follows:
1. From Visual Studio's Tools menu, select "Add-in Manager...".
2. In the list of "Available Add-ins", find "DevExpress Tools".
3. In the "Startup" column on the right, clear the checkbox.
4. Click OK.
5. Close VS.
Now, when you start VS, do this:
1. From the Tools menu, select "Load DevExpress Tools".
This will load CodeRush and Refactor!, and should prevent the error from occuring. |
Best Regards,
Mark Miller
Developer Express |
|
|
|
support
Whole Tomato Software
5566 Posts |
|
| |
Topic |
|
Topic Locked
