Change or specify plugins directory or folder location

[BlitzCoder]

Trying to figure out if this can be configured aside from the default location (beside notepad++) and I was expecting that it will look into the same base directory when you set the command line -settingsDir

It also creates an extra plugins folder at AppData/Roaming

[PeterJones]

@BlitzCoder ,

There are kindof two questions in one in this one, both with the answer “no, it’s not possible”.

First, it is not possible to define a different location for the plugin DLLs to go: plugin DLLs will always go in the .\Plugins\PluginName\ subfolder relative to the notepad++.exe, whether it’s an installation or a portable; whether it’s %AppData% or -settingsDir or Cloud Directory.

Second, the -settingsDir only affects certain config files, as enumerated in this issue – where the person requested that -settingsDir be made more like a “profile” setting (to include all settings) rather than just affecting certain files. If other users, other than the original requestor or one of the “forum experts” like me were to chime in on requests like that, it might help change the priority of those requests. So if someone like you were to chime in that you want that feature, and that you want it to include reading the plugins\config directory from the -settingsDir as well, it might increase the chances of that feature being implemented.

[rsonnier-cfs]

My 2 cents here as an avid and daily user on NP ++. We are a group of 4 developers all working on a RD server via RDP sessions. I have been having 2 related issues.

1- Since C:\Program Files\Notepad++\plugins is a common location for all users, I am unable to easily copy the latest (v6.24.10) dll in the folder since the .dll is always in use by several users; that is unless I ask everyone to close NPP. If NPP used %appdata% for the dll then each users could upgrade at will without interrupting others.

2- The reason I am trying to update the .dll is that NPP just locks up EVERY TIME I try to make any changes under “Show Formatting Options”. I then have to allow Windows to close the app and re-open. The changed settings do appear to save when re-opened. Is it possible that this issue is also related to the dll being locked? Or maybe NPP is simply not supported of RD server.

[rsonnier-cfs]

To clarify, the Plugin is SQLInForm. NPP locks up when I try to change the plugin settings not NPP settings. Nonetheless the issue with the plugin location is what is discussed here.

[PeterJones]

@rsonnier-cfs ,

If NPP used %appdata% for the dll

FYI: Feature requests cannot be processed here. We can only give our opinions or other feedback on a given request, but making a request here will not put it into the feature-request queue for the developers to look at. Our FAQ explains this.

–

If NPP used %appdata% for the dll

Prior to v7.6 (in 2018), plugins used to go in the %AppData%\Notepad++\plugins\ directory.

However, there were a lot of (valid) security complaints, and Notepad++ would have been essentially blocked from being installed in many corporate environments because it read executable code from the user-writeable %AppData% hierarchy. The developer didn’t want much of the corporate world to lose access to Notepad++, so in v7.6.3, Notepad++'s plugin interface was finalized to only allow plugins in the plugins\ directory off of the executable’s directory.

Given the security implications (and the massive loss of userbase if the developer ever enabled running DLL code from %AppData%\ again), I doubt any such feature request would ever be implemented (even as an option: if there is an option to configure Notepad++ to run DLL code from an insecure location, then the security hole exists, and the large userbase would be cut off from being able to use Notepad++). So, even if you were to ask for the feature in the right place, I would give it close to 0% chance of being implemented.

–

If you want a workaround, you could unzip a separate portable-zipped copy for each user into whatever directory structure you wanted, and then they’d each run out of that copy, and it would use the <portabledir>\Notepad++\plugins\ hierarchy for installing plugins, and thus there would be no conflict.

–

I am unable to easily copy the latest (v6.24.10) dll in the folder since the .dll is always in use by several users; that is unless I ask everyone to close NPP

The reason you cited is equally applicable to saying that Notepad++ itself cannot be updated while any users are using it. Unless you never update Notepad++ (which has security and performance and feature implications), then whatever window you use for updating Notepad++ could also be used for updating the plugins.

I highly encourage you to regularly update Notepad++.

–

If you want to get into the specifics on why SQLinForm is locking up when you try to make configuration changes, that is something that maybe someone in this forum could help you with. (I don’t have any experience with that plugin, but can give some generic statements.)

Plugins should have their configuration files in %AppData%\Notepad++\plugins\Config\ hierarchy, so just editing the configuration shouldn’t cause it to crash. Having multiple people using the DLL simultaneously shouldn’t change that (because they are presumably each executing it in a separate process), so I don’t see how any “lock” on the DLL file itself could in any way cause the instability you described. Unless SQLinForm plugin doesn’t use standard config file location and is trying to have some common config instead of per-user config, I don’t know how the location would affect things (and if they are doing that, your proposed change to the DLL location wouldn’t change their coding of a central config file, so wouldn’t help if that were the culprit.)

However, if there is a bug in an older copy of SQLinForm in general, which has nothing to do with DLL location, then you would necessarily need to do the upgrade to get it to work, regardless of whether the DLL is in a central location.

–

At this point, any possible fix will require making the users exit out of Notepad++ for some amount of time simultaneously: if the Notepad++ executable were changed to allow DLLs in the AppData (no matter how unlikely it actually is), they would have to exit so you could update the .exe; if you wanted to make a bunch of portable copies, on for each user, they’d have to stop using the centrally-installed exe and switch to their own portable exe; and if you just do an upgrade of the DLL now, they will have to stop.

–

Or maybe NPP is simply not supported of RD server.

It’s not specifically designed for multiple simultaneous users in a remote-desktop environment all running separate copies of the same executable, no. Notepad++ has the multi-instance mode, but it’s more focused on allowing a single user to have multiple windows of Notepad++ open simultaneously (for those for whom the two Views in the same window aren’t sufficient or not their preferred window setup)… but multi-instance has always had some drawbacks compared to single instance… and you’ve just found a rather unique use case showing yet another such drawback.