An ILSpy's plugin DLL cannot be copied to the ILSpy WindowsApp folder

[ndepend]

We plan to propose an ILSpy plugin for our product NDepend. When installing ILSpy from the Windows store, all ILSpy EXEs and DLLS get installed to a directory similar to:

C:\Program Files\WindowsApps\17310ICSharpCodeTeam.ILSpy_7.1.6543.0_neutral__jpqg2ewkdrg54\ILSpy

This directory can be obtained from the registry key:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\ilspy.exe

The ILSpy plugin README.txt states that: "Plugins must be placed in the same directory as ILSpy.exe, and must be called "*.Plugin.dll"."

However - even with administrator rights - no file can be copied in this WindowsApps directory. The procedure to have write access to the WindowsApps directory is overkill and hazardous.

Thus there is a fundamental incompatibility. Is there any workaround?

Since we can read the ILSpy Windows store directory we can still copy paste all ILSpy EXEs and DLLs in our own directory and install our plugin in this copied version. However when starting ILSpy from the Windows app our plugin won't be in.

On a side note we already have a Reflector plugin written a decade ago that solves this by writing a section like

[AddInManager]
"C:\Path\Lib\NDepend.ReflectorAddIn.dll"

in this config file: C:\Users\$usr$\AppData\Local\Red Gate\.NET Reflector\Reflector.cfg

[christophwille]

Quite frankly I have no idea how to do that, the MSIX implementation was contributed - and will go away in favor of the newly added setup post 7.2. The idea is to then distribute the setup in the "new" Windows 10/11 store that allows native installers.

And yes, I was aware that plugins might be a problem with MSIX. But the Store was never intended to be our main means of distribution.

[ndepend]

Thanks for the fast answer @christophwille,

>The idea is to then distribute the setup in the "new" Windows 10/11 store that allows native installers.

I am not sure to understand , will the new store let's copy plugin DLLs in the install dir?

>the Store was never intended to be our main means of distribution.

The idea would be to propose facilities to the user to locate the right instance of ILSpy on which to install our plugin. If the user has several instances he/she might need to install our plugin in several instances. At least our mutual users are .NET developers so they can get around with it with the right explanations.

I can see 4 means of distribution:

• Windows store: we can find install location with the regkey mentioned above but cannot copy in it
• Zip file from the ILSpy Release page: It seems there is no regkey registered when running the first time. Only the user knows where it is installed, am I wrong?
• MSI from from the ILSpy Release page I tried to open ILSpy_Installer_7.2.0.6791-preview3.msi with and without admin rights on a sane Windows10 machine with no luck. It starts show an install window with a progress but shut down almost instantly. I guess it should be installed in a dir like C:\Program Files (x86)\ILSpy\v7.2.0.6791
• Visual Studio extension (VSIX file) from from the ILSpy Release page: that installs in a dir like c:\Users\$usr$\AppData\Local\microsoft\visualstudio\16.0_aeaa6c81\extensions\m3nfu3xa.bvu\ILSpy\ILSpy.exe that we can find with a search algorithm (we already have btw)

In this circumstances our plugin is intended to be made of two lightweight files that can be copied to several ILSpy install if needed:

• NDepend.ILSpy.Plugin.cfg: that contains a path to the NDepend install directory on to resolve.
• NDepend.ILSpy.Plugin.dll: a net472 light DLL that installs our menus and bind with impl in the NDepend install directory provided in the config file.

Here is what it looks like in Reflector. No panel is added to the decompiler. We use an IPC to make dialog the two processes (our and disassembler one) so more features are available from the disassembler and we can decompile from our product (and also decompile 2 versions and then compare):

[christophwille]

Preview 3 had the first iteration of the installer - and no UI. That has changed since #2574 (the default install location hasn't, we tried to model VS Code). How that then behaves with the Store, I don't know (at the time we decided to drop the MSIX there was no documentation on native installers for the Store)

And you are correct that there are no registry keys for ILSpy when being xcopy-deployed. That is intentional and won't change.

[siegfriedpammer]

I might add that the only registry key that is currently modified by ILSpy is for the "Open with ILSpy" shell extension, but that happens only if the user clicks on the respective button in the "Misc" options panel. No automatic/implicit modification of the registry happens.

[ndepend]

We do also exclusively XCopy deployment and this has many advantages indeed. Ok we'll develop some heuristic to try locate a ILSpy.exe instance and when it'll fail the user will have to locate it manually.

Btw, one connected questions, will we have to provide a NDepend.ILSpy.Plugin.dll per ILSpy version (7.0, 7.1, 7.2...) or can we go with a single dll as long as it doesn't break on API changes?

[siegfriedpammer]

Btw, one connected questions, will we have to provide a NDepend.ILSpy.Plugin.dll per ILSpy version (7.0, 7.1, 7.2...) or can we go with a single dll as long as it doesn't break on API changes?

Sorry I for missing this question... yes, you should be able to use a single version of the plugin for all minor versions. We intend to only introduce breaking changes in major versions. If something breaks, please feel free to open an issue.

[ndepend]

Finally in WindowsApp install situation, we cannot do better than explaining the user the situation: