19 replies to this topic

[MarcusAK81]

Hi there,

i have some trouble to create a msi installer which can be installed by user which have no admin privileges. the main problem ist to register the com components per user without these admin privileges. Does anybody has an solution or a hint for solving that problem?


Regards Marcus

[Glytzhkof]

Are you using the advertisement tables for COM or are you trying to self-reg the files?

[Glytzhkof]

There is a new way to deal with COM btw, it is called registration free COM and works for in-process files (i.e NOT EXE files): http://msdn.microsof.../rfacomwalk.asp

[MarcusAK81]

At first thanks for fast reply.

Registering the components manually works (regsvr32.exe). The self-reg property not. Im looking for a way, that i can build my msi packages (using InstallShield DevStudio 9) in that way, that on all workplaces calling this installer it is possible to run the install without admin privileges. And there is the problem, that com are not registered cause of missing privileges.

By the way, its an interesting article about the registration-free components. Have to read this.


Regards Marcus

Edited by MarcusAK81, 27 September 2006 - 15:24.

[Glytzhkof]

To achive this you must enable the "COM extract at build" feature for the COM files in question. Please look this up in the help file. It is essentially just a flag in the property page.

[MarcusAK81]

Ok thanks for help, i will try this.

<edit>
It seems that it work.



Thanks for helping
</edit>

Edited by MarcusAK81, 28 September 2006 - 17:19.

[grisdeya]

If you are trying registrer a windows componentes requirement.. you will be problems with permissions and privileges ..

You must to use merge modules for install this components.

[Glytzhkof]

If properly advertised COM components are actually really registered per user when installed with MSI. The keys are written here I believe: HKEY_CURRENT_USER\Software\Classes (HKCR is a merge of the entries from HKCU and HKLM).

[MarcusAK81]

@grisdeya: With merge moduls i have teh same problems by registering

@Glytzhkof: I think its ok to write all keys in HKCR cause later they will be mapped by the system to HKCU or HCLM automatically.

[Glytzhkof]

Actually it is the other way around: HKCR is a merge of the Classes keys in both HKCU and HKLM. You need to properly advertise the COM information and set the ALLUSERS property appropriately to create a per user install. This should do the trick.

[MarcusAK81]

If ALLUSERS is not set, the installer does a per-user installation. Thats written in the help.

I tried with setting the ALLUSERS property buts the same like without. Module failed to register. The whole data of the application will be written in the users profile but the registration failed.

[Stefan Krueger]

Howis registration performed (Selfreg, or COM tables)? And how does it fail (error message, can you post the relevant part of the log)?

[MarcusAK81]

The registration is performed by SelReg. (Its the MSXML and THE SOAP redistributable).

[Glytzhkof]

You should most definitely not try to redirect the install of these merge modules. They are "semi-core" OS files and must be deployed with their respective merge modules. The best way to solve this is to deploy via a deployment tool that allows admin rights during install.

The overall problem is that these components can be used by many applications, and you will most likely break all the other apps on the system if you start redirecting. The registration free COM is possibly an option, but even that will be clunky.

[MarcusAK81]

A deployment tool cant be used and the probem that other applications could use this apps i can except.

The problem is that the user have to install a software and these software requires xml and soap and so all have to be installed by the installer. Users have only write acces in their users profile, thats why all have to be written in the users profile.

[Glytzhkof]

If this is in an SOE environment I would be very surprised if MSXML isn't part of the SOE. COM based SOAP on the other hand is a deprecated technology and is most likely not going to be on the system. Hence I suppose you could try to use registration free COM for the SOAP files and expect the SOE to have the MSXML.

[MarcusAK81]

I cant deprecate that msxml is a part of the soe the same by soap. The second thing is that the app need special verions of soap and msxml so i have to install them by installing the software and therefore i have to condiser thats there is no admin to do. Thats the problem.

[Glytzhkof]

I hope this does not sound rude, but I believe we have provided you with all the advice we can in this case. In my opinion there is something wrong with the overall design of what you are trying to do.

[MarcusAK81]

I know thats the project is something stranged. Thanks for help. And it sound not rude .


Regards
Marcus

[Glytzhkof]

OK great, please do share with us any solutions you come up with. We may be able to provide more detailed help. Remember: deployment is easy if you follow the rules, very hard if you break the rules.