StrataFrame and EnvDTE


Author
Message
Edhy Rijo
E
StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)StrataFrame VIP (6.4K reputation)
Group: StrataFrame Users
Posts: 2.4K, Visits: 23K
Hi Ben, Trent,
I am currently having some issues with DevExpress CodeRush product crashing VS 2013 & 2015.  For several days we have been debugging and testing several hotfixes they provided and somehow in my system it will always crash Visual Studio while not on their test computers.

So far this have been happening after I installed the SF VSIX in both VS 13 & 15 and we are wondering if the StrataFrame Extension installed with the VSIX makes any changes to the EnvDTE or have anything to do with it, before I am force to uninstall StrataFrame to continue testing as per DevExpress request?

Here is the link to the DevExpress support ticket:
https://www.devexpress.com/support/center/Question/Details/T289408#comment-58a294dd-0cfc-4b2a-831c-f04949140552

Thanks!!!

Edhy Rijo

Reply
StrataFrame Team
S
StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)StrataFrame Developer (6.5K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
I'll let Edhy reply, too, but I believe it did resolve his issues.  The root cause was that almost every AddIn/VSPackage has to use the EnvDTE Solution/Project/ProjectItem collection of interfaces to interact with the project system of Visual Studio.  VS is written in I'm guessing C++, and exposes the object model through COM objects by way of those interfaces.  The COM objects can be accessed from any thread without error until one thread takes explicit ownership of the object.  The partial classes are built on a background thread so the UI thread is not blocked.  VS does not appear to force the main thread to take ownership of any of the COM objects, so the background thread in the BOMapper can still access them.  However, it appears that something in CodeRush or other DevExpress component does force the main thread to take ownership, so as soon as they are accessed in the BOMapper, VS crashes because the AccessViolationException cannot be caught and VS just dies.  With Edhy's debugging help, I wrapped all of the access to the COM objects in calls to Dispatcher.Invoke() so they are all accessed from the main UI thread.  This is a good case study in one AddIn not knowing what the other is doing.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search