Updating the VB EXE
in [Visual Basic]
|
From: Nobody on 6 Oct 2009 23:08 "Eduardo" <mm(a)mm.com> wrote in message news:hagt3o$rcf$1(a)aioe.org... > Kevin Provance escribi�: >> "Eduardo" <mm(a)mm.com> wrote in message news:hagopm$n77$1(a)aioe.org... >> | Kevin Provance escribi�: >> | >> | > Since my installer (Inno) is download based (serious pascal >> scripting), >> | > meaning that new files are downloaded on demand, my app shells out to >> a stub >> | > of the installer to download the new file via a silent command line >> and then >> | > quite. >> | >> | But the UAC must ask for elevation to run that program... >> >> With Inno, you have your choice of running as admin or not. > > And how would it write to Program files\Application folder\ whitout admin > rights on Vista with UAC? It asks for elevation and the UAC prompt shows up and the user has to approve it, whether Inno is running silent or not. I think Kevin was referring to Inno having simple flags to run an executable elevated or not. See the page below and look for runascurrentuser(elevated), and runasoriginaluser(Not elevated unless the user used "Run As Admin"). When starting Inno, the user does not need to use "Run As Admin". Inno elevates later. http://www.jrsoftware.org/ishelp/topic_runsection.htm Inno Setup Online Help: http://www.jrsoftware.org/ishelp/
From: Kevin Provance on 6 Oct 2009 23:17 What "Nobody" said. The Inno download stub is included in the setup (actually, it IS the setup that copies itself to the Program Files\App dir with the update code executed by the \silent command line. Admittedly, I spent a fair amount of time writing and perfecting it). So, when my app checks for an update and finds one, and the user chooses to update, it shells out to the stub in it's own folder with the silent command line and all the work is done by Inno at that point. Now, in my case, there is a UAC prompt by the Inno stub, but it's a necessary evil as file registration is required in some cases in the event a new DLL or OCX is downloaded and needs registering. Could it be done without the prompt, probably, but by running you installer *not* as admin, I find it doesn't work like it should when AX is involved. "Eduardo" <mm(a)mm.com> wrote in message news:hagt3o$rcf$1(a)aioe.org... | Kevin Provance escribi�: | > "Eduardo" <mm(a)mm.com> wrote in message news:hagopm$n77$1(a)aioe.org... | > | Kevin Provance escribi�: | > | | > | > Since my installer (Inno) is download based (serious pascal scripting), | > | > meaning that new files are downloaded on demand, my app shells out to a | > stub | > | > of the installer to download the new file via a silent command line and | > then | > | > quite. | > | | > | But the UAC must ask for elevation to run that program... | > | > With Inno, you have your choice of running as admin or not. | | And how would it write to Program files\Application folder\ whitout | admin rights on Vista with UAC?
From: Kevin Provance on 6 Oct 2009 23:18 "Nobody" <nobody(a)nobody.com> wrote in message news:OgH11IvRKHA.1232(a)TK2MSFTNGP05.phx.gbl... | Is the EXE to be replaced inside "Program Files"? If so, then you would have | permissions problems as the "Users" group can't write to "Program Files" in | Windows 2000+. If this is company network, you can use RUNAS like Eduardo | suggested. In this case, create a user account for this purpose to make | things easy to manage. If it's meant for general usage, you have to use an | update service running under the local system account to perform the update. | There are commercial update services available, mostly in the range of | $200+. | Which - to add to this - is why I went the route of having an Inno stub deal with the permissions issue instead of coding them myself. But as I said in an earlier post, it's really only effect when using Inno to download files on demand.
From: Eduardo on 6 Oct 2009 23:56 Kevin Provance escribi�: > What "Nobody" said. > [...] > Now, in my case, there is a UAC prompt by the Inno stub, but > it's a necessary evil as file registration is required in some cases in the > event a new DLL or OCX is downloaded and needs registering. Just copying a file to Program files\* requires admin rights. (Or to Windows\*) > Could it be > done without the prompt, probably, Humm, no. I believe you can't do anything of that stuff without admin rights. > but by running you installer *not* as > admin, I find it doesn't work like it should when AX is involved. Yes, it won't work.
From: Michel Posseth [MCP] on 7 Oct 2009 01:14
You can do another nice trick , download the new executable , rename your current running executable ( give it bck or .prev extension for instance ) , copy your new executable to the location of the running executable show the user a message that he should restart the executable ( or kill the current app , and start the new exe ) the new exectable could on startup delete the previous files left over HTH Michel Posseth "Tony Toews [MVP]" <ttoews(a)telusplanet.net> schreef in bericht news:41inc55tl5eqk4j4d0s1bgm1u0kp79t2v8(a)4ax.com... > > Folks > > I'm going to be adding the ability to check for updates to my VB6 > utility. Now you can't replace an exe while it's actually being used. > Correct? I have had this happen to me a few times when I've been > testing the exe in a Virtual PC session, have switched over to the VB > IDE, fixed the bug, made a new exe and then haven't been able to > replace the exe because it was in use. > > To me the most elegant way is to create a very small VB6 exe whose > only job is to be called by the main VB 6 exe and to copy in the new > exe and start up the main app again. > > Now I could muck about with creating a one line .cmd file with a copy > line in it. But that, to me, just isn't all the elegant and is rather > a brute force approach. Not that I mind brute force approach but the > momentary flashing of the command prompt screen I find is rather > disconcerting when I see some apps using it. > > Any suggestions? Or is a little stubbie program the best option? > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > Granite Fleet Manager http://www.granitefleet.com/ |