Non-admin installer issues

[NomDeMorte]

Hi Tyrrrz :) Just updated to the new build to test the new --start-hidden switch (I think this naming is an improvement) since I use that feature as you know :)

Along with this, I got the new 'don't require admin' patch, which comes with some issues and experiences I thought I should share:

1. The old version is left behind when updating, so now I have one in C:\Program Files, and one in C:\Users.

2. Uninstall is version specific. This is probably a good thing, but to be clear, what I mean is that if I have both installed, when I run the uninstaller from the icon or from Windows' Settings control panel, it removes the new installation ... but the old one is still there. Running the uninstaller for the old one manually, worked fine, but I did have to use explorer to go find it since all the uninstall entries had been removed.

3. Uninstall does not remove settings. I can see why this would be useful, to allow reinstallation without requiring reconfiguring....but the uninstaller does specifically say, that the application has been "completely removed" and that's not quite true. Also, if someone has a problem, they may want to actually completely remove the application and it's settings, for a truly 'fresh' installation. I wonder how difficult it would be, to have an option in the uninstaller, to ask whether settings files should remain?

4. Settings location is installation location specific. When installing to the new default location, settings.dat was contained in the same directory as the .exe. The previous installation used the C:\Users<username>\AppData\Roaming\LightBulb directory for that file. As a result, settings are lost when updating. I was able to copy the settings.dat from the old location, this works fine, but I thought this worth mentioning. Particularly interesting, was that when installing to the Program Files directory, the settings file in 'roaming' is used once again (which is good, because if it were in the program's directory, the application started as the user wouldn't have permissions to overwrite it).... Which brings me to:

5. While I understand the convenience of the new location and recognise it will be better for some people, I actually want the program installed in the Program Files directory. This is both for reasons of organisation (I just like all my programs in one directory), and also for security (eg, the recent Discord vulnerability resulting from installation in a user accessible location). I attempted to do this and the installer failed, saying it had failed to create the directory, but didn't tell me why. Obviously (to me, but perhaps not to others in the future), it was lack of permissions, so I started the installer as admin manually, and it worked fine. This is when I noticed that my settings were gone, and as above, it was looking in the original location.

6. Dotnet runtime installation uses installer privileges. This one might be nothing or might be a real problem, with admin-free-installation. I noticed that the powershell windows which downloaded and ran the dotnet installers, were using the same privs as I had used to start the installer. So, when I ran the installer without admin, the powershell windows were normal ones. When I right-clicked and started as admin (to install to Program Files dir), the powershell windows were running as Administrator. Since I have the runtimes installed already, the installer exits without attempting to install, so I do not know if the installation of the runtimes would actually be successful, when the installer is run as the non-privileged user. Perhaps the dotnet installation would request the admin rights itself, I don't know. There is no entry to uninstall the runtimes, to attempt to re-install them as non admin user, so I'm sorry I couldn't actually test this.

7. Startup entry is updated and not installation specific. I thought you might like to know, that I didn't get any duplicates there, the existing entry was updated, and that removing the one created by the old version, works fine from the new version.

Bonus funny one: Don't accidentally install the test build at the top of the list on the CI download page, the one with the ever-growing log file. That could go wrong after a few days of uptime and zero free diskspace. LOL, glad I noticed that file growing, quickly after the installation ;)

Sorry for the long post, but I thought some of this might be useful information. None of this was really a problem for me, but I can see that there might be issues for other users in the future.

[Tyrrrz]

Thank you for testing it all out. You are right, there seem to be more cons than pros, I will revert this change. Please uninstall all versions of LightBulb you may have when that happens. :)

Bonus funny one: Don't accidentally install the test build at the top of the list on the CI download page, the one with the ever-growing log file. That could go wrong after a few days of uptime and zero free diskspace. LOL, glad I noticed that file growing, quickly after the installation ;)

Yeah, that was to help diagnose #102, definitely don't run that. I probably shouldn't have made that public.

[NomDeMorte]

I'm afraid that the settings still remain after uninstall.

[Tyrrrz]

@NomDeMorte just to clarify, you mean settings in "roaming app settings/LightBulb"?

[Tyrrrz]

Got it, should be fixed.

[NomDeMorte]

Awesome work man it's great. I tried to break it even with stupid regedits nobody would ever do, and it kept repairing itself ;)