Setup fails when the user's administrative account is different to their standard account

[girlpunk]

As per Microsoft best practices, my organisation is using separate accounts for standard and admin privileges. However, LINQBridgeVs' setup inside Visual Studio does not work correctly with this.

The issue is caused by a number of reasons; Visual Studio extensions are installed on a per-user basis, so initially the admin user did not have the extension to trigger the setup procedure. However, after installing the extension and completing the setup as an admin user, the standard user's install still claims to not be set up.

As a workaround, I copied the MsBuild targets file to the relevant program files folder, however LINQBridgeVs did not correctly recognise that this had been done, and still prompted to complete the setup as an admin user.

[codingadventures]

Hi,

Unfortunately copying the MsBuild target alone is not enough. The installation procedure also sets some configuration keys which are stored in the windows registry at this location: _\HKEY_CURRENTUSER\Software\LINQBridgeVs

The content of _HKEY_CURRENTUSER is different between users. Thus if you complete the LINQBridgeVs installation with the admin user then your standard user won't have those configuration keys available. There's no option at the moment to install linqbridgevs for every user, so until I finish the installer your only option is to copy the values stored here \HKEY_CURRENT_USER\Software\LINQBridgeVs for the admin user to the same location for the standard user.

[girlpunk]

If the MsBuild target is the only part of the setup that needs admin privileges, could the setup detect if the file is already in place (as it can likely be read without the privileges) and complete the setup (i.e. add the remaining reg keys) without UAC/admin rights?

[codingadventures]

You're right, that would be a smarter way of doing it. I will add a fix for it. However I'm working on a newer version, which will be compatible with VS2017 and 2019 only, and I am going to drop the configuration process, as it will be no longer needed.

[girlpunk]

If you're dropping the configuration process will that remove the need for admin privileges completely?

[codingadventures]

yes, the only reason for admin privileges to exist is to copy the custom target into the MsBuild folder . Although from VS 2017 it is possible to override or create custom build tasks by simply dropping a Directory.Builds.target file in the same solution folder. For backward compatibility with older versions of VS I had to keep the configuration process.

[codingadventures]

Fixed in the next release