Upgrade application when both bits application installed on single machine

Terry R

@Darshan-D-A said in Upgrade application when both bits application installed on single machine:

Can we have a solution for this, where another application is not removed from machine and upgrade is done ?

The reason you found this problem is that by default both versions use the same location for their configuration files (%appdata%\notepad++). These configuration files can only refer to one instalaltion. You will find the other installation still exists in the Program Files (x86)? but won’t run unless it uses a different location for the config files.

It’s possible when installing to tell the installer to use a different location for these configuration files and possibly you may want to setup both installations to use non-default locations. For further reading, the online manaul reference is here, look for “local configuration”.

Alternatively use one installed version and the other as a portable version, again reference is on the link above. In this case everytime the portable version is updated it resets the configuration files and this may be an unwanted side-effect.

I think your request for having both co-exist as you want (default installation configuration) is unlikely to get traction with the developer but if you did want to raise it as an issue see this FAQ post.

Terry

Mark Olson

Speaking as someone who currently has several versions of both 32bit and 64bit installed simultaneously, the solution is simple: don’t let Notepad++ update automatically. Download the 32bit installer for your desired version, and when it asks you if you want to uninstall 64bit, just click No.

Terry R

@Mark-Olson
So are you saying the default location %appdata%○notepad++ is supporting both versions? How is that possible?

Maybe that info would benefit by being added to the online manual if it isn’t particularly difficult to implement.

Actually if OP is using silent install would they get that message?

Terry

mkupper

I run a mix of x32 and x64 versions by using portable versions.

When I want to run a copy I use

c:\npp\~\notepad++.exe -settingsDir=c:\npp\Settings -multiInst

where ~ is the folder for the version of Notepad++ I want to use.

I use -settingsDir=c:\npp\Settings with all the copies of Notepad++. It’s an area where Notepad++ turns out to be very cool as I can seamlessly switch between old and new versions, x32, and x64.

There is one minor bug when you run Notepad++ with -settingsDir that the converter plugin that ships with Notepad stores its settings in c:\npp\~\plugins\Config\converter.ini rather than in -settingsDir. I’ve never used this plugin and so have never cared that its settings may be lost or at least not transferred/shared between my copies of Notepad++.

I don’t know if this would work well for @Darshan-D-A as I suspect the reason for having both x32 and x64 is to support legacy plugins. Like the converter plugin, some of them may not be aware of -settingsDir meaning to perform an upgrade you need to save the settings files for the plugins. The upside, is that the setting files are easy to detect as I could just expand the zip file for the old/existing version into a folder and do tree-compare the folder against the one for the running copy of Notepad. The files that are added/removed/changed are the ones I would need to pay attention to.

At one point I wanted to try an old version of Notepad where there was an installer.exe copy on a machine. I downloaded a portable copy of the version I wanted to use and ran it with -settingsDir="%AppData%\Notepad

Alan Kilborn

@Terry-R said in Upgrade application when both bits application installed on single machine:

So are you saying the default location %appdata%\Notepad++ is supporting both versions? How is that possible?

Why wouldn’t it be possible?
It is my understanding that it’s just configuration info stored there, and that should be bitness agnostic?

Terry R

@Alan-Kilborn said in Upgrade application when both bits application installed on single machine:

It is my understanding that it’s just configuration info stored there, and that should be bitness agnostic?

Ive been pondering more on this question overnight and in principle I agree. I’ve checked my NPP config files and nowhere are there references to the bitwise locations (that I can see). I even looked at how the plugins seem to be referenced, and they don’t seem to start with the %appdata%\Notepad++ folder. Rather it seems the bit version looks to it’s own program files (x86)? plugin location to start identifying the plugins, and they in turn go to the %appdata%\Notepad++ folder to get their own configuration data (possibly not all cases though).

But I do believe it would be a bad idea to mix it up using a common config across the 2 bitwise applications. Reasons below:

multi session. We have the possibility that both bit versions could running at the same time. If this setting active of course last session to close (even across the bit versions) could be the one setting config files in the %appdata%\Notepad++ folder. If OP sets it to be not active but still runs both bit versions at the same time, the same result could occur and that wasn’t the OP’s intention.
backup files enabled. Both bit versions will likely be running their own set of files. The lists most likely will differ from one session on 1 bit version to the next time it runs, so OP could lose backups. Not totally a problem if OP follows accepted guidelines and also sets up a more enhanced backup regime as referenced in the FAQ post. The possibility exists for 1 bit version to work off files in a remote/removable location and that location may not be available when the alternate bit version runs.
similar to #2 for the project panel and folder as workspace. Setting these for 1 bit version is OK, but also may not be what the OP wants in the other bit version.
for the reason @mkupper put forward of using both bit versions as one is supporting a legacy plugin that the later versions of NPP don’t support. That together with the need to “silently install” suggests this is a real possibly. So in this case we have config files supporting two disparate versions of NPP. My understanding of this is that when one version is updated it does not immediately update the config file. The reason being is that may overwrite a user setting with a new default. However setting that new option will write that to the config file. I presume the older bit version will just ignore the new setting as not applicable (hopefully). Even though it doesn’t support my concept of being a bad idea I get uneasy about this type of setup.
One of my original questions was if a silent install, would the OP get the message to NOT uninstall the alternate bit version?

I refered to the idea of using a “non-default” settings directory during installation, I still think that would be the wisest way. Just keep the two apps seperate and then configurations could be made completely independent (provided backup folder set appropriately as well). If this was used I’d even go as far as to suggest both installations use something like “64Notepad++” and “32Notepad++” as folders under %appdata%. Then both could be silently installed without one removing the other. As the OP may well be in IT support (just 1 reason why silent install may be used), knowing that 2 different configuration folders were used would help immensely when comes time to “fix” any possible corruption or other similar issue (views or panels not appearing as beyond display borders seems to be a reoccuring theme).

So I stand by to be corrected. I suppose a lot of my reasoning may not be correct, rather it’s conjecture based on my own use of NPP over the years, and also seeing the posts where users experienced issues in their own installation and how they were remedied.

Terry

Coises

@Terry-R said in Upgrade application when both bits application installed on single machine:

Rather it seems the bit version looks to it’s own program files (x86)? plugin location to start identifying the plugins, and they in turn go to the %appdata%\Notepad++ folder to get their own configuration data (possibly not all cases though).

Plugins, including any data that is installed with them, are found in subfolders of the plugins folder inside the installation folder. This is important for security — you wouldn’t normally want installed, executable code in a folder that could be modified without admin privileges and UAC intervention.

Plugins use NPPM_GETPLUGINHOMEPATH to determine the plugins directory and NPPM_GETPLUGINSCONFIGDIR to determine the directory in which they can store user-specific data.

Terry R

@Coises
I realize that’s where the plugin app resides. My comment was in how the plug-in is acted on by NPP. I thought one of the configuration files in %appdata"\Notepad++ would reference the plug-ins used but it seems that the knowledge of which plug-ins are available is directly from the program files folder for each NPP folder. Is that correct as you see it?

Terry

PeterJones

@Terry-R said in Upgrade application when both bits application installed on single machine:

I thought one of the configuration files in %appdata"\Notepad++ would reference the plug-ins used

There is no config file that tracks the plugins installed/loaded.

but it seems that the knowledge of which plug-ins are available is directly from the program files folder for each NPP folder. Is that correct

That is how it works. the notepad++.exe scans the Plugins\ folder relative to the executable path for NAME\NAME.dll and loads those DLL. Plugins Admin and Debug Info and the Plugins Menu knows what plugins are available based on that scan.

update: @Coises and I were apparently working on our answers at the same time.

Coises

@Terry-R said in Upgrade application when both bits application installed on single machine:

it seems that the knowledge of which plug-ins are available is directly from the program files folder for each NPP folder. Is that correct as you see it?

Yes. My recollection is that on startup, Notepad++ will look for a plugins folder in the same folder as the executable; it will then enumerate folders within the plugins folder, then check each folder for a dll with the same name as the folder. It will then attempt to load those dlls and make some calls to specific entry points in those dlls that must proceed as expected to register the plugin (else a message about an invalid plugin will be shown).

There was some discussion in this forum — I think not too long ago — about the possibility of individual users in a multi-user environment being able to enable or disable individual plugins, with the ability to install plugins still being limited to administrators; but that proposal was never pursued.