This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Restricted user behavior
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 24, 2011
09:39 AM
Restricted user behavior
What can generate the following behavior?
I have a Basic MSI package which requires Administrative privileges.
I install it under an administrator account. Then log in as a standard user and start a new installed application.
The MSI Installer starts and after a while asks for admin credentials or fails, depending on the Windows version. It's like a repair is requested.
So, what setting in the ISM project design can force a 'repair' at the first run of any of the installed features (apps)?
PS. I have another, very similar, project that do not behaves like that.
Thanks for any suggestion,
Ioan
I have a Basic MSI package which requires Administrative privileges.
I install it under an administrator account. Then log in as a standard user and start a new installed application.
The MSI Installer starts and after a while asks for admin credentials or fails, depending on the Windows version. It's like a repair is requested.
So, what setting in the ISM project design can force a 'repair' at the first run of any of the installed features (apps)?
PS. I have another, very similar, project that do not behaves like that.
Thanks for any suggestion,
Ioan
(11) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 24, 2011
10:29 AM
You have mentioned that when you start the newly installed application this repair comes up that means the installation is going into self repair, a possible cause for this could be that some dependent files that are required to run the application is missing, so the installer detects that and goes for the repair.
Check all the files that are needed for the appliaction is there or not? Also try to create the Log file and see which component is missing ...
Check all the files that are needed for the appliaction is there or not? Also try to create the Log file and see which component is missing ...
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 24, 2011
02:44 PM
All the files are there...
I looked in the log file generated on that 'repair' and there are some suspicious things:
- The feature I test is says: Installed: Local; Request: Reinstall; Action: Reinstall
Why reinstall?!?!
- a list of components with 'special' names: __ComponentName65 where ComponentName is a valid (known) component name. Going through that list I think they are all components that write in Registry (COM, .NET COM, etc) and all my .exe files; I cannot find any trace of these weird names (__Compo...) in my project tables
- The 'repair' seems to enforce the reinstall of all the components for the current installed feature (the .exe I started when 'repair' was triggered). The common components (installed with all the features) are not reinstalled.
Maybe all these would tell something to an expert...
I looked in the log file generated on that 'repair' and there are some suspicious things:
- The feature I test is says: Installed: Local; Request: Reinstall; Action: Reinstall
Why reinstall?!?!
- a list of components with 'special' names: __ComponentName65 where ComponentName is a valid (known) component name. Going through that list I think they are all components that write in Registry (COM, .NET COM, etc) and all my .exe files; I cannot find any trace of these weird names (__Compo...) in my project tables
- The 'repair' seems to enforce the reinstall of all the components for the current installed feature (the .exe I started when 'repair' was triggered). The common components (installed with all the features) are not reinstalled.
Maybe all these would tell something to an expert...
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 24, 2011
02:48 PM
Other test:
- Install under Administrator;
- First run the app -> 'repair' occurs, application starts;
- Run second time -> app starts;
- switch users to User1;
- First run app -> 'repair' runs, the app starts;
- Run second time the app -> starts;
- Switch back to Administrator (or any other user);
- First run the app -> 'repair' occurs (again!!!) , application starts;
- Run second time -> app starts;
- Switch back to User1 (or any other user);
- First run the app -> 'repair' occurs (again!!!) , application starts;
- Run second time -> app starts;
All the MSI logs show like in the above post - at least what I can figure out.
And it not hapening only for a standard user, for any user, including the Admin that just installed it!
Any idea? Anybody?
- Install under Administrator;
- First run the app -> 'repair' occurs, application starts;
- Run second time -> app starts;
- switch users to User1;
- First run app -> 'repair' runs, the app starts;
- Run second time the app -> starts;
- Switch back to Administrator (or any other user);
- First run the app -> 'repair' occurs (again!!!) , application starts;
- Run second time -> app starts;
- Switch back to User1 (or any other user);
- First run the app -> 'repair' occurs (again!!!) , application starts;
- Run second time -> app starts;
All the MSI logs show like in the above post - at least what I can figure out.
And it not hapening only for a standard user, for any user, including the Admin that just installed it!
Any idea? Anybody?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 24, 2011
09:15 PM
for the feature which is going to reinstall, do one thing go to the setup design view and try to make all the components ".Net setting -> .Net Scan at build" from "Dependencies and Properties" to "None " which are under that feature and then try it. Will the setup still goes to repair mode ?do let us know?
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 25, 2011
09:37 AM
Thanks for the suggestion but... it did not help. 😞
My settings are anyway by default "Properties only", but I did what you asked. For all components, even if only one is .NET COM Interop = Yes.
Also, I set to None for all other .NET COM Interop components (the common ones), not only the one from the feature. All my features behaves the same (the repair bevahior).
My settings are anyway by default "Properties only", but I did what you asked. For all components, even if only one is .NET COM Interop = Yes.
Also, I set to None for all other .NET COM Interop components (the common ones), not only the one from the feature. All my features behaves the same (the repair bevahior).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 25, 2011
10:10 AM
Does your setup use any mergemodules or anything ?? can you attach the logfile when it goes for repair or try to see the components that is causing the self repair
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 25, 2011
11:30 AM
I do use 2 merge modules, but in the log attached I removed one. The remaining is the CrystalReports merge module.
Like I said yesterday, it's looking for some weird component names __ComponentName65 which are not in my project (or, at least, I cannot see them).
I attached the log for the case discussed yesterday.
Like I said yesterday, it's looking for some weird component names __ComponentName65 which are not in my project (or, at least, I cannot see them).
I attached the log for the case discussed yesterday.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 25, 2011
12:44 PM
I removed all the merge modules.
Same behavior: first time running the app does the repair.
(Maybe one exception, but I think I saw it before: for the Admin user is not doing the repair, only for the others - standard users)
Same behavior: first time running the app does the repair.
(Maybe one exception, but I think I saw it before: for the Admin user is not doing the repair, only for the others - standard users)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 25, 2011
03:38 PM
None of the above files (components) are part of the merge modules.
All of them are part of the installed feature.
For all of them I set the .NET Scan at Build = None, but only DigiDictateProxy.dll has .NET COM Interop = Yes.
All of them are part of the installed feature.
For all of them I set the .NET Scan at Build = None, but only DigiDictateProxy.dll has .NET COM Interop = Yes.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 26, 2011
12:52 PM
Case closed!
I found what generates that behavior:
In the project I had a component set to install into [TempFolder] folder. Removing it fixes my problem.
I found it from Events viewer where it was reported as missing. Why was that??? Who knows, Microsoft secrets :rolleyes: .
Thanks to mano.n.s75 who spend some time with me.
I found what generates that behavior:
In the project I had a component set to install into [TempFolder] folder. Removing it fixes my problem.
I found it from Events viewer where it was reported as missing. Why was that??? Who knows, Microsoft secrets :rolleyes: .
Thanks to mano.n.s75 who spend some time with me.