Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Extracting COM Registration


11 replies to this topic

AntonS

AntonS
  • Full Members
  • 94 posts

Posted 11 August 2004 - 09:41

Hi,

InstallShield X Automation Interface proposed ExtractAtBuild property of ISWIComponent object. The property intended for

For latter question I find next in documentation for SelfRegister property of ISWIFile object:

"You can also mark .exe, .tlb, and .olb files as self-registering."

Thereby, InstallShield X propose two methods of COM registration:
1. Set ExtractAtBuild of ISWIComponent object
2. Set SelfRegister property of ISWIFile object

First extract registry information in build system at build time, Windows Installer write it to registry at install time.
Second extract registry information by calling own DllRegisterServer at install time.

Which one is prior by other?

Thank you
Sincerely your,
Anton Spitsyn
http://www.installsite.ru

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 11 August 2004 - 09:54

COM Extract at build is the preferred option. It takes place when your setup is built, and provided it is successful all COM info is written into your database. This has a number of benefits including support for your setup being advertised, registering COM servers per user if you install setup per user etc... If you use COM extract at build you are not supposed to use the Self-Register option. Self registration involves calling RegSvr32.exe on the COM dll you want to register when the setup is run on the target system.
Regards
-Stein Åsmul

AntonS

AntonS
  • Full Members
  • 94 posts

Posted 11 August 2004 - 16:33

Can COM extract at build approach increase essentially time of build?
Suppose, all extracted registry information will store in windows installer Registry table?
Sincerely your,
Anton Spitsyn
http://www.installsite.ru

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 12 August 2004 - 03:42

Yes, COM extract at build will increase the build time. How much depends on the complexity and number of COM servers. If the COM servers don't change much you can add them statically to your installation database. Add them using the Installshield wizard so the COM data is extracted correctly and put into the appropriate tables. Don't add all the data to the registry table, they should go into TypeLib, Classid, etc.. tables in order for advertising to work correctly.
Regards
-Stein Åsmul

VicJHR

VicJHR
  • Members
  • 6 posts

Posted 12 August 2004 - 14:43

Does anyone know why windows installer sometimes adds the value "InprocServer32" to the key "InprocServer32"
HKCR\CLSID\{...}\InprocServer32\InprocServer32
with the data of this value being a stupid set of charachters ?

What are the curcomstances for such effect to occur?

For example - the installation of ISWI 2.03 writes to key
HKEY_CLASSES_ROOT\CLSID\{00020420-0000-0000-C000-000000000046}\InprocServer32
a value with the same name "InprocServer32" having data like a piece of memory.
this causes known problems :
http://support.micro...om/?kbid=329134
http://support.micro...kb;en-us;298110

Otherwise the installation of DevStudio8 doesnot do such things !!!


Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 13 August 2004 - 09:33

Double posted, followup here: http://forum.install...showtopic=10535
Regards
-Stein Åsmul

Malinovka

Malinovka
  • Members
  • 3 posts

Posted 16 June 2005 - 12:06

IS 10.5

How to disable advertising support for COM components?

I have to make local installation for developers, and they should be able to register their own version of COM serers (debug versions for example). But setup prevents it, by restoring dll's and ocx.sad.gif

How disable advertising? I didn't found a solution in MSI help. install site is the last hope

ANo

ANo
  • Full Members
  • 179 posts

Posted 16 June 2005 - 16:44

I need a little help:
We have the same problem like VicJHR, Malinovka.

We use InstallShieldX Prof..

It's a trouble with the InprocServer32-Value in the key HKCR\CLSID\{...}\InprocServer32.
Is this an error ???

We have a lot COM Objects.

We can not make an installation project for developers
with self registration and the same installation project for customers with COM extraction.

How we can prevent it, but using the COM extraction during the build?

Thank You
André

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 17 June 2005 - 13:12

You could try to blank out the component GUIDS for the components installing COM servers. Not sure if the COM extract will still work, and I definitely do not recommend the approach for anything but debugging.
Regards
-Stein Åsmul

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 17 June 2005 - 13:14

There is also a property called something like DISABLEADVERTISEDSHORTCUTS that disable the self repair for advertised shortcuts (or so I believe). However, COM server info and file association will still function as MSI entry points for self repair and you will hence probably still see the self repair happen.
Regards
-Stein Åsmul

Malinovka

Malinovka
  • Members
  • 3 posts

Posted 17 June 2005 - 14:30

Taken from MSI help lib.

OLEAdvtSupport Property

The installer sets the OLEAdvtSupport property to true when the current user's system has been upgraded to work with installation-on-demand through COM. Note that for the installer to register a COM class and enable installation-on-demand, the class must be listed in the Class and ProgId tables.

Setting this property to "false" in proeprty editor does nothing:(

No one knows?
I thought it is a simple question:(

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 17 June 2005 - 15:41

It is a simple question, and I am afraid the answer is also simple: MSI is a deployment technology. The self repair feature is one of the core features of windows installer, and as such is very difficult to disable. However, as I wrote above (don't know if you read it), it may work to remove the component GUID from the component that installs the COM file. I have never tried this, and I don't know if the COM extract would still work.

Other than that you can: Self register the files instead of using COM extract (this is not the recommended way to do it, but if the package is just for development use it shouldn't matter). You may want to disable advertised shortcuts as well. To self register the files use either the standard windows installer SelfReg table, or the ISSelfReg table the latter should also allow registration of EXE files as far as I recall). Finally: you could use a regular script based installer during the development phase instead of windows installer.
Regards
-Stein Åsmul