On Jan 22, 2008 3:01 PM, Rick Schummer <[EMAIL PROTECTED]> wrote: > A setup.exe will automatically raise permissions via UAC or the user will > have to enter the admin > password when it is executed. The bigger problem you face is the rights for > the folder being set so > the users can write to the tables.
Hi, Rick, and thanks for the answer. It's apparent I haven't explained the problem very well. Sorry. This is a vertical niche application installed at a number of customers across the country. Clients run it on their network. This is the client's line-of-business application, running 100% of the time they are doing business. They share the DBC and DBF via a CIFS/SMB file share from their server. Installation on each desktop of a VFP7 application is done using an administrative logon and an InstallShield(limited Edition?)-built setup.exe, so they get the standard security features that setup provides, as well as FoxPro runtimes, registry entries, etc.. The business changes regularly, and we are constantly updating, modifying, enhancing and occasionally bug-squashing. When a particular site is ready for a new version (some sites every couple of weeks, some sites once or twice a year), we dial in and place an updated exe on their network server. Each time anyone launches the application, the loader EXE sees there is a new version on the server, copies it down to the local folder (C:\Program Files\OurApp), and launches it. (Occasionally, an update requires a datachange, which we can usually execute overnight, when no one's in the app. Very rarely, we have to do an "everyone out of the pool" maneuver.) We supply the software; each of our clients has either in-house expertise or a local "computer guy" to install-configure-maintain and fix the printer jams., maintain the network, internet access, security, etc. On some of the more secure sites, they already have strict policies in place and have had to script an exception so that our direction in Program Files is writeable. If the process of copying the .EXE file will raise a UAC dialog and let a supervisor temporarily log in with an admin password to complete the operation, that would be ideal (i.e., no code changes needed). However, if the operation just fails, that would be a problem. Obviously, we'll need to test this. > Doug has a blog entry (which you likely have seen) on how he uses > Inno to update the permissions on the data folder. > > http://doughennig.blogspot.com/2007/12/where-should-data-go-in-vista.html Thanks for the reference; we'll have to consider this as an option. > As to your question about the InstallShield Express Limited edition working, > I have heard from > others that it won't work on Vista, but I have not tried it myself. I know if > you are limiting OS > options on the install it won't work by default because the newer OSes are > not in the list, so they > cannot run the installer. This is something we'll need to test, of course. For this application, we have a fairly stable base of customers we service, so the install is years old but serves to get the base files onto a new (or newly-re-installed) workstation. The first run of the app loads the updated EXE (and any other updated files). Is there a set of Windows API calls that would allow us to determine that the directory is protected and bring up the "Run As" dialog to allow the loader to run as admin, install the new file, and then restart in user mode? > I am not sure an APP is the better route as it will need VFP to run, or you > will have to create the > EXE to wrap a call to the APP file. We're already using a loader application to check for a new version anyways. I'm wondering if the right solution is to copy the APP from the network to a user-controlled local applications settings directory and launch it from there. > The loader might not have access rights to copy the APP file > anyway. At least with the setup.exe you get the behavior to raise the > security level to initiate and > make the install. The base install certainly needs, and should have, administrative rights to the machine and the controls and checks that entails. That's a good thing. After that, though, I'm looking for the most painless route to maintaining the updates to an application. Once XP is no longer for sale in July, clients will have little choice but to get Vista machines. If recent history is any guide, we can expect each of our clients to get a different version, install in different security contexts and require us to cope with the fallout. Thanks for the clues. Obviously, I'll have to do some testing here, but you've pointed me in some good directions to research. Others with suggestions would be welcome! -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
