Re: ILSpy Visual Studio Plugin / Add-In - SourceFly

Simple and low priority: instead of Browse Source, perhaps something like "Browse with ILSpy" so it's more clear

Please consider a config file (or Tools -> Options seteting) where I can specify the path to ILSpy. Your addition to automatically navigate to an assembly is slick, but if ILSpy receives a significant update, and your forked version does not, then I can't use it. Perhaps an alternative (making this up as I type) is to have your splash wrapper /navigateTo the first Type found in the specified assembly? It's not the same as just highlighting the assembly node as you have done, but highlighting something at the top of that node's subtree is pretty close. Plus it will allow your users to continue to use the official ILSpy distribution. Ideally, ILSpy source would add navigateTo options for (A)ssembly and (N)amespace in addition to the ones it already has.

You mentioned that this isn't 100% complete. Do you have plans to implement other features?

Re: ILSpy Visual Studio Plugin / Add-In - SourceFly

I was thinking of keeping things generic with "Browse Source" since, in theory, my plugin can be used to call any program that navigates assemblies. In practice, the only program is ILSpy, so I'll change it to "Browse with ILSpy" like you suggested.

Regarding the path to ILSpy, I was thinking of having the user choose the path to ILSpy during installation. This path would be stored in the registry or a config file like you mentioned.

The forked version is temporary until the official distro includes this feature. However, if someone has a newer version of ILSpy, nothing will break - it just will not auto navigate to that node when opening. I am not calling ILSpy with non standard parameters.

By "not 100% complete" I mean there are some outstanding issues in parsing the code and determining correct assemblies:

1. In some instances of code I am not correctly determining the type. So, you may come across some code where ILSpy says the type cannot be found. For example, I am parsing Method(int param1, int param2) but if there is a Method(int param1, out int param2) I may not have coded how to handle the "out" yet.

2. Different versions of Visual Studio, in different types of projects (web, assembly, winforms, silverlight, etc) allow me to determine the correct assembly to load to varying degrees of success. This still needs work.