Hello Appdeploy forum,

could you please navigate mi how to import file association from registry into a component but to have it imported into correct tables not only to registry table.

Thank you.
xxMBxx
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
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
Answered 12/02/2009 by: Scazy
Senior Yellow Belt

Please log in to comment
0
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.
Answered 12/02/2009 by: VBScab
Red Belt

Please log in to comment
0
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
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
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
Answered 12/02/2009 by: Scazy
Senior Yellow Belt

Please log in to comment
0
...which isn't much use if people want to take advantage of advertising, though.
Answered 12/02/2009 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
VBScab, give me please short example why it is not comfortable in case of advertising.
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
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.
Answered 12/02/2009 by: VBScab
Red Belt

Please log in to comment
0
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
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
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.
Answered 12/02/2009 by: AngelD
Red Belt

Please log in to comment
0
Well, does it means that VBScab owe me apology? [;)]
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
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
Answered 12/02/2009 by: AngelD
Red Belt

Please log in to comment
0
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?
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
he probably means ProgID advertising
Answered 12/02/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
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.
Answered 12/03/2009 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 12/03/2009 by: xxMBxx
Orange Belt

Please log in to comment
0
Threat?!?Do not write to HKCR, instead use HKLM\software\classes or HKCU\software\classesNo, use the advertising tables.
Answered 12/03/2009 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 12/03/2009 by: AngelD
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity