Prev: Asking Advice
Next: Outlook 2007 and second inbox created
From: GS on 26 Feb 2010 18:11
MikeD pretended :
>
> "Webbiz" <nospam(a)noway.com> wrote in message
> news:1pdgo5p44617ujd589h8j7ug4fv5dsvp34(a)4ax.com...
>>
>> Now, assuming you meant "install" failed, that I've seen happen with
>> Windows 7. The usual way to deal with that is to make sure you run the
>> install by selecting "Run as Administrator". Seems Windows 7 will
>> prevent some support files from being copied into its protected
>> directories and/or bother registering them.
>>
>> To "Run as Administrator", simply right-click your installation file
>> and select it from the popup submenu.
>
> While I don't mean to discourage this as a sure-fire way to run the setup
> with admin rights, it's not necessary if the file is named Setup.exe
> (variations are also supported, but I don't know right off-hand exactly what
> those variations are). Windows will automatically elevate to admin IF the
> logged on user is a member of the Administrators group. I'm also pretty sure
> any Windows Installer package, regardless of file name, will get elevated
> since it can only be an installation (or patch/update).

Actually, on my Win7 64-bit system, which I normally login in as a
member of the Administrators group, some protected areas were not
updated by the installer (i.e.: Registry keys used by the app <other
than those under HKCU>). When I ran the installer using the "Run as
admin..." option from the context menu it installed properly. Note that
this happened when the installer was copied to the machine. When the
file is downloaded to the machine it seems to behave as you describe
here. (ergo it automatically elevated to Administrators group)

So this suggests the installer behavior depends on how the file gets
onto the target machine.
>
>
>> One last thing. Some older apps, even if you install everything just
>> fine 'as administrator', will have some hickups. VB6 itself I've found
>> to have this issue on my machines. To get around this, you right-click
>> the program icon, select Properties, then Compatiblity tab. Click on
>> the "XP SP3 Compatibility" checkbox and also the "Run as
>> Administrator" checkbox.
>>
>> Whether this is what you're 'suppose' to do, I can't swear to it. But
>> it is how I solved many of my Win 7 issues with apps from XP and
>> older.
>
> Those should usually be considered as last resorts; i.e. there's no other way
> that the app will run properly and there's no newer version
> available...especially running the app with admin rights. Ideally, the app
> should be re-written to be compatible with Vista and Win7. You might,
> however, need to use compatibility UNTIL the app is re-written, or perhaps
> permanently if the app is no longer supported at all.


From: GS on 28 Feb 2010 18:27
I stand corrected! Your comments made me look deeper into this because
they just make sense<IMO>. I have not been able to duplicate the
scenario I described in my previous post. The installer behaves exactly
as you state, and which is also how I thought it should work. This was
obscured by my app being launched at the end of installation (to
initialize licensing) and it failed to run. Turns out the cause is
related to user rights and not running of the installer. I implemented
Joe Priestly's access permissions solution in my installer and all
works correctly now.

Kind regards,
Garry

MikeD expressed precisely :
>
> "Webbiz" <nospam(a)noway.com> wrote in message
> news:1pdgo5p44617ujd589h8j7ug4fv5dsvp34(a)4ax.com...
>>
>> Now, assuming you meant "install" failed, that I've seen happen with
>> Windows 7. The usual way to deal with that is to make sure you run the
>> install by selecting "Run as Administrator". Seems Windows 7 will
>> prevent some support files from being copied into its protected
>> directories and/or bother registering them.
>>
>> To "Run as Administrator", simply right-click your installation file
>> and select it from the popup submenu.
>
> While I don't mean to discourage this as a sure-fire way to run the setup
> with admin rights, it's not necessary if the file is named Setup.exe
> (variations are also supported, but I don't know right off-hand exactly what
> those variations are). Windows will automatically elevate to admin IF the
> logged on user is a member of the Administrators group. I'm also pretty sure
> any Windows Installer package, regardless of file name, will get elevated
> since it can only be an installation (or patch/update).
>
>
>> One last thing. Some older apps, even if you install everything just
>> fine 'as administrator', will have some hickups. VB6 itself I've found
>> to have this issue on my machines. To get around this, you right-click
>> the program icon, select Properties, then Compatiblity tab. Click on
>> the "XP SP3 Compatibility" checkbox and also the "Run as
>> Administrator" checkbox.
>>
>> Whether this is what you're 'suppose' to do, I can't swear to it. But
>> it is how I solved many of my Win 7 issues with apps from XP and
>> older.
>
> Those should usually be considered as last resorts; i.e. there's no other way
> that the app will run properly and there's no newer version
> available...especially running the app with admin rights. Ideally, the app
> should be re-written to be compatible with Vista and Win7. You might,
> however, need to use compatibility UNTIL the app is re-written, or perhaps
> permanently if the app is no longer supported at all.


From: Webbiz on 1 Mar 2010 15:48
On Fri, 26 Feb 2010 17:29:29 -0500, "MikeD" <nobody(a)nowhere.edu>
wrote:


>While I don't mean to discourage this as a sure-fire way to run the setup
>with admin rights, it's not necessary if the file is named Setup.exe
>(variations are also supported, but I don't know right off-hand exactly what
>those variations are). Windows will automatically elevate to admin IF the
>logged on user is a member of the Administrators group. I'm also pretty sure
>any Windows Installer package, regardless of file name, will get elevated
>since it can only be an installation (or patch/update).


This brings up a subject that I've been meaning to address.

While many call their setup programs "Setup.exe", I like to them named
after the application itself because I have to deal with so many setup
files for various apps, placing them in their proper website
directories, etc. Just like them independently named.

So what I was wondering I think you addressed. What do we do to make
installation packages that will fully install the .exe and supporting
files by simply running the installer without the need to "Run as
Administrator"?

I've been using InnoSetup to create my setup packages. Perhaps I
should be learning how to create .MSI package? Thoughts?

Thanks.
:-)
Webbiz
From: GS on 1 Mar 2010 16:18
I don't see why you can't use whatever naming convention you like. I do
similar to what you are suggesting and it works for me with organizing
files the same as you do. I append the AppID to "Install" when saving.
The AppID is a code I use to identify the app and its version. For
example, version one of an invoicing app might have this AppID: "INV1".
Version two would be "INV2". So the installers are named
"InstallINV1.exe" and "InstallINV2.exe", respectively. You could even
implement minor and build values if desired: (i.e.:
"InstallINV2.2.11.exe")!
--

Whether or not our installers will run without admin rights depends on
a lot of things, but usually requires admin rights by default <AFAIK>
because they can make fairly significant (and otherwise unauthorized)
changes to a system. If you need to set app folder permissions and
Registry access permissions then the install must be done by an admin
group member. In most corporate environments this is dictated by group
policy, and some totally disallow this to be done on client machines
across the network. I'm sure some of the VB6 vets here will have more
to say...
--

Garry
--

Webbiz laid this down on his screen :
> On Fri, 26 Feb 2010 17:29:29 -0500, "MikeD" <nobody(a)nowhere.edu>
> wrote:
>
>
>> While I don't mean to discourage this as a sure-fire way to run the setup
>> with admin rights, it's not necessary if the file is named Setup.exe
>> (variations are also supported, but I don't know right off-hand exactly what
>> those variations are). Windows will automatically elevate to admin IF the
>> logged on user is a member of the Administrators group. I'm also pretty sure
>> any Windows Installer package, regardless of file name, will get elevated
>> since it can only be an installation (or patch/update).
>
>
> This brings up a subject that I've been meaning to address.
>
> While many call their setup programs "Setup.exe", I like to them named
> after the application itself because I have to deal with so many setup
> files for various apps, placing them in their proper website
> directories, etc. Just like them independently named.
>
> So what I was wondering I think you addressed. What do we do to make
> installation packages that will fully install the .exe and supporting
> files by simply running the installer without the need to "Run as
> Administrator"?
>
> I've been using InnoSetup to create my setup packages. Perhaps I
> should be learning how to create .MSI package? Thoughts?
>
> Thanks.
> :-)
> Webbiz


From: Nobody on 1 Mar 2010 17:03
"Webbiz" <nospam(a)noway.com> wrote in message
news:0o9oo5tfg7mhcdj4fhjj724d8rfrj3e944(a)4ax.com...
> While many call their setup programs "Setup.exe", I like to them named
> after the application itself because I have to deal with so many setup
> files for various apps, placing them in their proper website
> directories, etc. Just like them independently named.

<SNIP>

> I've been using InnoSetup to create my setup packages. Perhaps I
> should be learning how to create .MSI package? Thoughts?

If you are renaming "setup.exe" that is generated by Inno Setup to something
else, just change "OutputBaseFilename" setting so you don't have to rename
the file. Example:

OutputBaseFilename=MyAppSetup

See also "OutputDir" in the help.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Asking Advice
Next: Outlook 2007 and second inbox created