Solved!
I get nuts trying to install Visual Studio .NET 2005 add-ins. E.g. I tried to install the
VSFileFinder2005 add-in.
Now it seems that VS.NETisloading the add-in,Filemon tells me the add-in is being accessed by VS:
(Image file:http://magerquark.com/data/misc/vsfilefinder2005-01.png)
But in the options it tells it is broken:
(Image file:http://magerquark.com/data/misc/vsfilefinder2005-02.png)
And in the Add-in Manager dialog it doesn't show up at all (only another add-in that isnotinstalled through the xcopy deployment installation way):
(Image file:
http://magerquark.com/data/misc/vsfilefinder2005-03.png)
Question: Can someone help me solving this?Any place to look for debugging (logfiles?) that VS.NET writes why it can't/won't load the add-in?
I also had VS 2005.NET Beta 2 installed before installing the final version. Maybe it is an issue with that?
Thanks
Uwe
[1810 byte] By [
UweKeim] at [2007-12-23]
Hi,
The first thing to fix is that the add-in should appear in the Add-in Manager. This can be done through registry entries or an XML file. Once installed and loaded, if VS finds an error during the load, it can prompt to disable it (maybe this happened on your machine). Contact the add-ins docs to see how to install or register it.
Uwe,
If you unable to get VSFileFinder installation issue resolved you might wanna take a look at my free add-ons collection called DPack. One of its features is called File Browser, which is basically VSFileFinder on steroids. One fundamental difference between add-ins and DPack is that it's a VSIP package. Packages are typically a lot easier and more straight forward to install, and they are not susceptible to add-ins registration issues.
Good luck and hope this helps.
Thanks, Sergey, I already did this, your DPack runs correct on my machine
.
The two main advantages of VSFileFinder compared to your tool is:
- The filter window is modeless and dockable as a normal panel.
- The filter text box allows for multiple entries separated by white space to be filtered for, combined internally with "AND".
Maybe you are interested in enhancing your tool in that way, so one would not need VSFileFinder anymore.
Thanks
Uwe
Advantages is rather subjective topic. 
It basically boils down to VS toolwindows vs. modal dialogs design approach. I strongly feel toolwindows is not the the right approach most of the time for 2 reasons. 1 - I value my VS real estate and don't want extra clutter. And 2 - toolwindows are always there and thus require some sort of polling most of the time (VS code model just doesn't cover all scenarios), which slows down VS editor. I much prefer deterministic functionality that modal dialogs bring.
I don't want to further hijack this thread and turn it into product comparison, so lets follow up at www.usysware.com/forums/. Thanks.
Not exactly sure why and how, but now my add-ins are working.
This reply here is intended to help others who suffer from the same problem, maybe my solution helps them, too.
What I did today (beside other things, but I think this one fixed the issue) was installing the Microsoft SQL Server 2005 Client components, including the SQL Server Management Studio 2005.
Now, suddenly, all my add-ins are working and are displayed correctly in the add-in dialog in Visual Studio.NET 2005:
(Image file: http://magerquark.com/data/misc/vsfilefinder2005-04.png)
I really have no clue why the Management Studio had an effect on Visual Studio, but probably they are sharing common libraries/settings and installing the Management Studio repaired some of these formerly broken settings.
So probably re-installing Visual Studio.NET 2005 would have had the same effect.
Anyway, I'm happy now 
.
Hi Sergey,
It is interesting to see the comparison between your addin and mine. I haven't installed DPack but from your web site it looks like it has lots of great features that VSFileFinder does not include.
I was able to avoid doing any polling in VSFileFinder by hooking up various events. The only timers I use are to avoid repeated updates when there are a flood of events. The addin also uses various other tricks to avoid slowing down the IDE.
I still prefer tool windows for this kind of thing as it allows the addin to behave in a similar way to the solution explorer and does not obscure the current document when the addin is being used. On the other hand I can fully understand your point about screen space.
Jon Payne
Hi Jonathan,
I hope I haven't offended you in any way with my earlier reply (judging by your reply it didn't seem like I have, but just in case). I know a lot of VS developers much prefer VSFileFinder's toolwindows approach to modal dialogs. I do get occasional requests for toolwindow support but haven't made up my mind about it, until 2 days ago. <g> I was watching Scott Hanselman's dev tools presentation, CodeRush part in particular. Man feels strongly about how he wants his tools to work, and more importantly, the direction he thinks productivity tools will head in the future. So, I started thinking that perhaps some people do want non-modal solution.
I can't even closely approach CodeRush's VS integration level so toolwindow is the best I can do. Thus, I'm considering adding toolwindow support for DPack in the next version.
Thanks for clarification on VSFileFinder updates. I'm gonna investigate this further and see if I can hook into VS hierarchy events.
Hi Sergey,No offence taken - if your addin switches to using toolwindows, I might consider switching to it myself.
I have to admit that, although I use events, I gave uptrying to work out the effect of each individual event. Instead, I just
trap almost all the events I can find and use them to trigger a refresh after
100 ms or so (to avoid refreshing constantly if Visual Studio sends lots of
events).
Jon
 Jonathan Payne wrote: |
| I have to admit that, although I use events, I gave up trying to work out the effect of each individual event. Instead, I just trap almost all the events I can find and use them to trigger a refresh after 100 ms or so (to avoid refreshing constantly if Visual Studio sends lots of events).
|
|
I took a quick look at what VSIP makes available to me and IVsTrackProjectDocuments2 and/or IVsTrackProjectDocumentsEvents2 (reside in Microsoft.VisualStudio.Shell.Interop.dll for the record) is what should probably work for me.
Because of your finding I'm very happy now too, thanks. The problem was
MSXML6 which is a requirement of
SQL Server Management Studio 2005.
