6 replies to this topic

[sjimmerson]

Not sure if this is a bug with DevStudio 9 or MSI or not, but we are having an issue where files marked as self-register are failing when publishing or assigning to a user via Active Directory (AD). One begs the question then--Why not just use "Extract at Build" for those component? Well we had issues with "Extract at Build" that we did not have when using self-register. Now we have issue with self-registe!? <sigh>

Here is some info from the Windows Installer help topic "Custom Action Security":

The installer runs custom actions with user privileges by default in order to limit the access of custom actions to the system. The installer may run custom actions with elevated privileges if a managed application is being installed or if the system policy has been specified for elevated privileges.
___

Since the installation is being run with elevated priviledges ISSelfRegisterFiles should also run with elevated privileges according to the aforementioned help topic, but that does not appear to be the case. I say this because when the installation is deplyed to an admin user it works just fine. Trying to manually register the files under a restricted user account produces the same errors that are displayed during the installation as well.

Anyone have any experience with this? It does not appear to be working as described in the help. Am I missing something? Does anyone have any suggestions?

Thanks,
Shane

[Stefan Krueger]

I don't think that ISSelfRegisterFiles runs in system context, which means that it will impersonate the current user.
You can try this: go to Tools > Options > Preferences and switch self registration from the InstallShield method (ISSelfReg table) to the Windows installer method (SelfReg table) to see if that helps. Note that you need to remove and re-add the file after that change.

However in general COM extaction is recommended. Maybe you should better try to fix that problem.

[Zweitze]

If the package is only designed for one domain (ie you're deploying the software), you can also consider to give restricted users modify access to HKEY_CLASSES_ROOT. Note this weakens the security.

However, I do suggest you get the Extract at build working, most problems I know arise from the fact that multiple copies of the file are present on the build system, but the source DLL (that will be used in the build) is not registered. As a result, Extract at Build does not find any registry information linked to the DLL.

[sjimmerson]

I agree. I would prefer to use "Extract at build" as well.

Zweitze,

I want to make sure I understand your suggestion. Are you saying "Extract at build" does not work properly if the source file is not registered on that PC? Is this only an issue if a copy in a different folder is registered? Is this documented somewhere or is this based off of your experience? I will check into this and see if it makes a difference.

Stefan,

I considered using the SelfReg table, but it does not work for EXEs according the the documentation and we have two EXEs that need to be registered that are currently being marked as self-register.

Thanks,
Shane

[Stefan Krueger]

You could register your exe using a custom action (run exe installed with the product). You should add a similar action to unregister during uninstall.

[Zweitze]

This is the way it is (and I have tons of experience on this), but I never found clear documentation on this.

For a better understanding, Extract at build (probably) works this way:
Open all regkeys under HKCR\CLSID. Check the subkey InprocServer32, if the value is the same value as the source, the class will be included. Next, look at ProgId, AppId, etc.etc. You get the idea.

It does *NOT* work like this: Load the DLL, call DllRegisterServer, and track all activities until it's finished. Therefore, special implementation, for instance that sets extra keys in HKCU, will go unnoticed.

Once you got this working, I suggest you create a dedicated build system. On this system:
* NEVER install the software it is supposed to build. The reason: a new copy of your DLL is registered!
* Better, just install the compiler, InstallShield, your Build software, a virusscanner and nothing else.
* Make sure you register the dll before building, and unregister it after building. Never replace the dll with a newer version without deregistering the old copy first (why? If a class is removed, the information will remain in the registry. Every time Extract at build will detect this class, and set include it with your DLL...)

Hope this helps.

[sjimmerson]

Zweitze,

Wow, that sounds like a royal pain. I will try your recommendations to see if it corrects our issues with "Extract at build".

Thanks for the feedback.

Shane