Restricted user behavior

[#1]

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

[manomatt]

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 ...

[#3]

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...

[#4]

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?

[manomatt]

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?

[#6]

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).

[manomatt]

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

[#8]

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.

[manomatt]

if you remove both the merge modules and then try installation will this issue come up or not ??

Refer teh attachment and can you tell me if these components are part of mergemodule or so ??

[#10]

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)

[#11]

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.

[#12]

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.