So plugins technically exist two places: C:\Program Files\Wasatch Photonics\ENLIGHTEN\Enlighten\pluginExamples and C:\Users\mzieg\Documents\EnlightenSpectra\plugins.
The reason we copy the plugins from Program Files to Documents is so end-users have write access to them, can add their own, can edit ours etc.
Originally, we had the Documents plugin tree be installed by InnoSetup. That way InnoSetup knew which files it created, and on uninstall, it would remove "default" plugins (any from our standard distribution), but leave any "new user" plugins. Then when re-installing a newer version, it would again copy-in the distro plugin set, interleaved over anything the user had created.
I think this broke on customer OneDrive setups or something, where the Documents\EnlightenSpectra that InnoSetup saw wasn't the "runtime" Documents\EnlightenSpectra that enlighten.exe saw.
So the system was changed such that enlighten.exe (technically, enlighten.Plugins.PluginController.stub_plugin) would copy the tree over itself. And that currently happens.
However, it only happens ONCE. If you upgrade to a new ENLIGHTEN version, you're not getting the new plugins (like Prod.BurnIn) in EnlightenSpectra\plugins, because it sees the tree is already there and won't overwrite it.
I think it would be a simple improvement for stub_plugin to "merge" the old tree and new, similar to what InnoSetup did: for every plugin in pluginExamples (part of our distro), overwrite what it finds existing. Perhaps, if the old version differs from the new, rename to .bak so we don't risk destroying something the customer modified (this would leave useless .bak for anything that we updated between versions though).
If we wanted to get fancy (I don't), we could leave an EnlightenSpectra/plugins/.install-manifest.json with MD5 of what the previous installer copied from its pluginExamples, and we could then silently overwrite any old-but-different files whose current MD5 matched the manifest, meaning Wasatch updated it in the distro, not the customer. We could basically release that install-manifest.json as part of our release process, so it would be part of our distro (pluginExamples/manifest.json).
Anyway, for now I'm solving MY problem by deleting my old EnlightenSpectra/plugin folder, but this problem shouldn't be dumped on the users.
So plugins technically exist two places: C:\Program Files\Wasatch Photonics\ENLIGHTEN\Enlighten\pluginExamples and C:\Users\mzieg\Documents\EnlightenSpectra\plugins.
The reason we copy the plugins from Program Files to Documents is so end-users have write access to them, can add their own, can edit ours etc.
Originally, we had the Documents plugin tree be installed by InnoSetup. That way InnoSetup knew which files it created, and on uninstall, it would remove "default" plugins (any from our standard distribution), but leave any "new user" plugins. Then when re-installing a newer version, it would again copy-in the distro plugin set, interleaved over anything the user had created.
I think this broke on customer OneDrive setups or something, where the Documents\EnlightenSpectra that InnoSetup saw wasn't the "runtime" Documents\EnlightenSpectra that enlighten.exe saw.
So the system was changed such that enlighten.exe (technically, enlighten.Plugins.PluginController.stub_plugin) would copy the tree over itself. And that currently happens.
However, it only happens ONCE. If you upgrade to a new ENLIGHTEN version, you're not getting the new plugins (like Prod.BurnIn) in EnlightenSpectra\plugins, because it sees the tree is already there and won't overwrite it.
I think it would be a simple improvement for stub_plugin to "merge" the old tree and new, similar to what InnoSetup did: for every plugin in pluginExamples (part of our distro), overwrite what it finds existing. Perhaps, if the old version differs from the new, rename to .bak so we don't risk destroying something the customer modified (this would leave useless .bak for anything that we updated between versions though).
If we wanted to get fancy (I don't), we could leave an EnlightenSpectra/plugins/.install-manifest.json with MD5 of what the previous installer copied from its pluginExamples, and we could then silently overwrite any old-but-different files whose current MD5 matched the manifest, meaning Wasatch updated it in the distro, not the customer. We could basically release that install-manifest.json as part of our release process, so it would be part of our distro (pluginExamples/manifest.json).
Anyway, for now I'm solving MY problem by deleting my old EnlightenSpectra/plugin folder, but this problem shouldn't be dumped on the users.