Better way to install VFP9+Innosetup application?

[Vince Wen]

I have a VFP9 application that uses Inno Setup as its installer. I am facing a challenge because most of our users install the application on a network server. The issue arises because Inno Setup cannot recognize mapped drives when elevated privileges (admin rights) are required during installation. As a result, users must install the application using the UNC share name.

Unfortunately, many of our users are not technically savvy leading to a constant stream of support calls for assistance with installing the application to the correct UNC share location.

My question is: Is there a better way to handle this situation? I can't be the only one dealing with this issue in a FoxPro application using Inno Setup. I would appreciate any ideas or workarounds that others in the community might have.

Additional Note:
- After the initial installation, the Inno Setup wizard can prepopulate with the previously installed path (the correct UNC share name). However, due to changes in personnel or computers, users often do not use the same computer for updates each year.
- We have a new version released each year which must be installed in the same location each year. Making this a recurring problem.

Thanks in advance,

Vince

 

[Jeremy H]

Well, if you knew what the unc share path was, you could create a cmd file that would map the drive in the administrator context, and then run the installer. It might need to be created for each customer, but then they could run the cmd file As Administrator, and it would work.

You might be able to create a program that would run in the user context and collect the drive mappings, and either store them for the install program, or have it create the cmd "wrapper" that would run in the administrator context, and remap the drives.

 

[Vince Wen]

Unfortunately, we have too many customers to create individually...

 

[Chriss Miller]

If possible you could start a secondary EXE that acutally requires no elevation and thus runs in the user context, which could have the dialog to chooss the drive letter and determine the UNC path for it, as is necessary for the main setup process.

Because when you map a network share you can choose three options:

1. Reconnect at sign-in
2. Connect using different credentials
3. Connect to a website that you can use to store documents and picture (OneDrive, I think not only one drive, also any FTP connection)

Well, The first option is the usual one and tells you that mappings are only reestablished at sign in of users. That means you can't get at them. But a process running under the normal user account - therefore actually enforcing no elevation for a helper exe, could see that and then store it from wher the setup can pick it up. This idea still requires the user that has the mappings to start the setup and elevate from there, but software installation might be done by an admin or by software configuration management be assigned to clients, which means you can't rely on a helper exe to see the mappings, necessarily.

There could be a simpler way, yet. Simpler? Well, at least with more control on your side and more options on top of that. It's based on what you already have:

- After the initial installation, the Inno Setup wizard can prepopulate with the previously installed path (the correct UNC share name). However, due to changes in personnel or computers, users often do not use the same computer for updates each year.

I assume this prepopulation works, as you store that information somewhere local, llike the registry, where it can be found next time. But only on the same client.

Well, so store it on your website for each company, retrieve it from there. It would obviously require the setup to be able to know the company. But instead of knowing or determining that you could ask for entering a registration key during setup, which you hand out and keep uniquely different for different companies but the same for the same company, which indirectly identifies the company. You could also use it for licensing purposes and against software piracy, but it would simply give you a unique identifier to retrieve whatever set of data you want to know from the previous/initial setup, as you store that associated with the registration key as id during the initial setup, any upgrade setup and then get at it again in the current setup. Not finding something stored on your website would idenntify an initial setup, well, or someone trying piracy.

Obviously this change requires two iterations, next time to be established to then be used the following time, but as it offers more options, I think it would be worth it, wouldn't it?

 

[Vince Wen]

Thanks Chriss, I have gone with your first suggestion. Basically have innosetup call a helper.exe to retrieve UNC path. I got it to work (mostly). Thank you.

Your second suggestion has the benefit of solving some of our other problems. It will take a bit more thought, but the main issue is it requires us to be SOC2-type2 compliant due to web services required. Which is a pain...