Software Deployment

to be more concrete, I have reg file with 50 pieces of file associations and would like to convert these reg file into correct tables(extension, ProgID, Mime) using Install Shield.

Hi xxMBxx,
1) If your project file is an ISM than find a related file with your extension that has key path as a file (EXE, DLL, OCX..) and then go to advanced setting and click to "extract com data for key file". that should register them over the tables
2) if yout project file is an MST then you need to register them by hands or use tools like the COM Register or write your own

Eh? The OP wants to know how to populate the advertising tables connected with file associations.

MB, I would like to help but the VM I have with IS is busy with another project right now and I just *can't* remember how IS handles .REG imports.

As a "suck it and see", I'd suggest capturing the import to an MSI and merging that with (a backup of) the target MSI.

Hi Scazy,

are you speaking about exe,dll,ocx registration or about .pdf,.xls,.doc registration. I am affraid I would like to talk about .pdf,.xls,.doc file association.

thank you
xxMBxx

For .pdf,.xls,.doc extensions you need to register them by hands. In my experience there are everytime something that can not be registred over the tables and I recommend just to split extensions to siutable components and leave them in the registry table under HKCR

...which isn't much use if people want to take advantage of advertising, though.

These was the way which I finaly did it. But I have prefer HKLM\Software\Classes instead of HKCR. I have remember that HKCR was created just for 16 bit application compatibility or?

Scazy wrote: In my experience there are everytime something that can not be registred over the tables
xxMBxx: Yes you are right, I have try this workaround to fill aproximatelly 80 associations isolated in registry file into correct tables:
1. run repackager
2. import reg file with 80 files associations
3. run repackager, create msi
4. now the file associations are in correct tables but the rest of the data which can not be registered over desired tables are direclty inside registry table.

so the conclusion for me is, import the reg file into component with holds exe keyfile. I will not prefere to import it into correct tables because not everything could be imported and I see no disadvantage in having it inside registry table.

VBScab, give me please short example why it is not comfortable in case of advertising.

HKCR was created just for 16 bit compatibilityHoly cow...I have to be honest and say that I'm stunned that people with such a lack of basic Windows skills are let loose on this stuff. I'm going to stop giving advice to you right here: if this is the level of your knowledge, I can see you wreaking serious havoc.

The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.

http://msdn.microsoft.com/en-us/library/ms724475(VS.85).aspx

Well, it also says:
This key also provides backward compatibility with the Windows 3.1 registration database by storing information for DDE and OLE support.

Well, does it means that VBScab owe me apology? [;)]

I'm not the judge so that will be up to Ian ;)

Sounds weird that MS refer to 16-windows; include support for 16-windows (OS) in a 32-bit windows like NT, 2K, XP, Vista, Win7 and Win2008?
I would guess they mean it was added in an early version of windows for 16-bit application support and is left to support (be compatible) with very! old applications :)
However, everyone (applications) uses it now

Good afternoon Ian, would like to ask you for additional help, could we go further and could you please put a light on my last question?

he probably means ProgID advertising

VBScab, give me please short example why it is not comfortable in case of advertising.I don't understand your question. My point was that, if you use the Registry table, you lose out on the advantages of advertising. Additionally, if your package uses the correct tables, registration information will get written to the correct hive, either HKCU or HKLM, depending on whether it gets installed per-user or per-machine respectively. Do not write directly to HKCR.

As for the MS article you pointed to, I have no idea why MS would include that caveat: I can't even work out what that caveat actually means, since it states that, up to NT 4.0, HKCR was a simple alias for HKLM\Software\Classes. The SDK article linked at the bottom of the article mentions nothing about 16-bit backwards compatibility.

conclusion from this thread:
1. Do not write to HKCR, instead use HKLM\software\classes or HKCU\software\classes.
2. It is not possible to import registry file(.reg) with file associations into InstallShield responsible tables(ProgID,Extension,Mime), instead the registry file is directly imported into registry table.
3. Workaround for point 2 is over repackager which fill up responsible tables then is possible to copy and paste it to original MSI, disadvantage not all file association registry entries could be inside correct tables(ProgID,Extension,Mime) so the rest should stay in registry table.

Threat?!?Do not write to HKCR, instead use HKLM\software\classes or HKCU\software\classesNo, use the advertising tables.

ORIGINAL: xxMBxx

conclusion from this thread:
1. Do not write to HKCR, instead use HKLM\software\classes or HKCU\software\classes.

If you do use the Registry table to write the COM-Component registration, you want to add registry under HKCR (Registry.Root=0) so you don't have to mess with if the installation is per-user or machine as this will be handled automatically.