I am working on updating my CR_Documentor community plugin tool window (source here) to allow installation into Visual Studio 2015. This includes:
* Using VSIX manifest v2.0.0 format.
* Building in Visual Studio 2015 using the VS 2015 SDK
When I debug the project, things work great. I see my Document or tool window added to the list of the other tool windows as expected and it behaves well.
Screen shots:
(1) Before running the installer and before debugging, you see all the tool windows listed.
The trouble comes when I actually install the VSIX to test it. Before I upload to the VS Gallery I want to make sure it works.
I exit VS 2015 and double-click the VSIX to install it. The process executes successfully. That's screen shot (2) - showing the VSIX correctly detecting that it can be installed into VS 2015.
On startup of VS 2015, the only tool window visible anymore is the Documentor window. That's screen shot (3) - showing only the tool window for the installed community plugin. Also, the plugin doesn't actually completely work - it seems to miss events that it expects to be raised from the DXCore engine, like doc parsing events.
Uninstalling the VSIX allows CodeRush to work again as expected, but something has become corrupted. Now that I've tried to install the VSIX into the VS Experimental instance, debugging yields the incorrect experience where I only see the tool window plugin and no other CodeRush features work, nor does my add-in work.
I'v e attached a zip to this ticket with the noted screen shots and a copy of the VSIX I'm using to test. The source is on GitHub.
Thanks for providing your plug-in. I have installed it but can't reproduce the behavior you described. The ""CodeRush\Toolwindows" menu contains all CodeRush items and the new "Documentor" item:
Please remove cache files of the CodeRush loader and check if it solves the issue on your side. For this, remove the following folders:
%appdata%\CodeRush for VS .NET\1.1\Settings.xml\Loader
%appdata%\CodeRush for VS .NET\1.1\Settings.xml\_Scheme_FrictionFree\Loader
If the issue persists, then provide us with your CodeRush settings and point what options scheme you use (you can see the active options scheme on the DXCore Visualize Toolbar). CodeRush settings are located in this folder:
*%appdata%\CodeRush for VS .NET\1.1\Settings.xml*
I am looking forward to your response.
Sure enough, clearing that cache seems to have fixed it. Very odd. Makes me wonder if the cache somehow gets corrupted as you debug VSIX add-ins or something. Granted, not the primary use case, but that's the only thing I can think of that I did differently here - I first tried to debug it (one VS instance debugging another - the Experimental instance), then I restarted VS and installed it for real. Somewhere in there, the cache got messed up.
Thanks for helping me out on this. I'll have to file this for future reference. :)
We are happy to hear that clearing CodeRush loader cache files solves this issue. Feel free to contact us if you need any further assistance with your plug-in.
As it turns out, I'm still having a heck of a problem with this when trying to debug VSIX add-ins.
I tried to capture logs for this, but the second instance (Exp) doesn't generate logs into the CodeRush message list. I can't open the Options in the second instance, even with a direct hot key. The options window for the add-in I'm debugging actually shows up in the VS instance that is running the debugger rather than in the instance being debugged, indicating there's some sort of "sharing" of some nature going on between the two instances, like it's one global instance of CodeRush across the two VS instances and that's causing some nature of corruption during debugging.
Thanks for providing the screencast. I have tried to reproduce this issue by your steps but the "CodeRush\Tools" menu loads correctly on my side. I have recorded the screencast illustrated It:
http://screencast.com/t/CwkwMpCeQH
To determine what causes this issue on your side, please collect CodeRush log files and provide us with them. For this, perform steps described in the following Knowledge Base article: How to collect diagnostic logs?
Also, I recommend you remove the following folders:
%localappdata%\Microsoft\VisualStudio\14.0\ComponentModelCache
%localappdata%\Microsoft\VisualStudio\14.0Exp\ComponentModelCache
During development of extensions for Visual Studio 2015, we noticed that old cache files in these folders sometime caused issues with loading updated extensions.
I am looking forward to your response.
OK, I am back in business. I had to not only delete the …\14.0\ComponentModelCache and …\14.0Exp\ComponentModelCache, but also the …\14.0Exp\Extensions contents. It appeared that the debug version of a previous extension (CR_Documentor, from when I was working with that) was still in there and having that as well as the VSIX installed version was causing some fits.
Nuking all of that allows me to get in and debug the next extension.
Thanks again for your help (and patience!) with all of this. DevExpress support has always been the best and this is why.
Thank you for the compliments. We are happy to hear that you have solved this issue.