Darwin Descriptor
Filed under:
Wise Package Studio
Basics
Submitted by WiseUser on 21 July, 2008 - 16:36.
Darwin Descriptor registry is an encoded value used by Windows Installer under registry like HKEY_CLASSES_ROOT\Excel.Sheet.8\shell\Open\command\
The encoded data in "Command" string value resolves to a specific product, component and feature.
Windows Installer decodes the specific component and checks its presence on the system. If the component is not available it triggers the MSI product repair.
This is one more reason why a Vendor MSI should never be captured. As this encoded information (if captured) will be an invalid reference. Normally this information in an MSI is stored as Advertised CLSIDs for the particular file.
(22 votes)
- Login or register to post comments
- 1512 reads
- Printer-friendly version
Nice piece of information
Nice piece of information "WiseUser".
Darwin Descriptor is actually an encoded representation of a specific product, component, and feature.
As there are three types of advertise entry points for windows Installer product. It can be advertise shortcut, or File association or can be COM Server.
Darwin Descriptor may cause problem for repair or may affect funcationality of application.
for file associations it can be seen under \shell\open\command or COM Server can be under HKCR\CLSID\{X...X}\Inprocserver32
The value may looks like encoded value such as e.g.
c^28+iyyshsjgs8262&%"02$0w773011`22
If MSI database is properly recorded for Advertise table then try to avoid such values in registry table. While installation sequnce Advertise table get install first and then registry table. So chances that your registry may update with false value.
Solving ICE 33 warning is painful but it helps here.
Regards
Harsh
How to these Capture Advertised CLSID's
Nice one.
I am really in need of this. Currently I am working on a script, basically capturing vendor MSI, I am facing issuses in Capturing some of these files on Vista machine.
It seems that I am not able to Capture these, as I did some small analysis after going thru this and found that the vendor msi is creating encoded value HKEY_CLASSES_ROOT\<>\shell\Open\command\
Please suggest me how to resolve this.
WiseComCapture
WiseComCapture.exe which get install using Wise Package studio automatically capture Advetise Com information when you actually do setup capture.
Com information is stored into any registerable Dll or Ocx file(can be recheck using registering Regsvr32.exe).(some exe's & tlb files are also registrable & include com info).
Make sure you not taking capture of vendor MSI.
If you in doubt, you can
Add file into component, then right click on that component, check the checkbox says "Rescan the advertise information during compile".
If any com info/adv info missed before, may get added when you compile your MSI.
Regards
Harsh
Yeah. Wise Comcapture is
Yeah. Wise Comcapture is the right away to do this.
check this below tip to understand better.
http://juice.altiris.com/tip/2983/how-manually-reg...
Capturing the Vendor MSI
Thanks for the useful information and tips.
However, I am capturing from the Vendor MSI. Please let me know how to resolve in this context.
(reason for capturing vendor MSI: 1. We use Wise as the Main Packaging Tool 2. To Remove the dependency on Install Sheild Script)
you should not capture Vendor MSI
You should never capture the Vendor MSI. 1. Wise is a good tool to create MST for Vendor MSI's.
2. If there is no Custom Action in the package who has dependency on Installshield script then you can delete all InstallShield entries in the mst file. It has worked quite a number of times for me. But actually it depends on the situation and package. I will not say that this will surely work for you, but I will recommend strongly not the recapture the MSI, this will only create problems. Just try out, there must be some work around. Let us know if you face some particular problem while installing MSI with MST. there are lots of experienced people here who can help you out.
Tauntt....huhhhhh
Piyush... was that a taunt??? ;) h ehe heee..!!!
Well, Dont take it serious buddy !!!
hehehehe...
Not much but kind of... hheheee...
I just wanted to safeguard myself, in case u again pounce on me :D
well one point which i wanted to convey was that the reason he mentioned that one of the main reason he was repackaging the MSI was that they are using WISE as the tool... I dont think Wise is such a bad tool that you have to reacpture the MSI..
Well the points you have mentioned below are really good...
hi Hareesh,When vendor MSI
hi Hareesh,
When vendor MSI tries to register a dll, it does it through regsvr32.exe (many a times) and this is referred in the application as well. Sometimes, you can also SelfReg entries in the MSI table.
Vendor MSI:
In this issue which you have mentioned, I reckon there is a dll ISbridge.dll which would be referred in few Custom Actions in the package. Try commenting these actions and it shouldn't ask for ISScript.
FYI: We had done few packages with pre-requsites of ISScripts. Solving ISScript 9,10 or 11 is quite easy. We did face a little difficulty with ISScript 11.5
While Capture:
Try to register this dll using wisecomcapture.exe and add these registries to that respective component. IF it doesnt work., then you can use a regsvr32.exe in a Custom action to register the dll.
Why dont we capture a vendor MSI:
High Importance
1. There would be a change in Product code or upgrade code, hence applying patches will be a problem to the product.
2. Not all CA will be captured becuase of the conditional installation.
3. Darwin descriptors significance.
3. All the Component Conditions will not be available for further installs.
Low Importance
4. Few of the components will have the same GUID for a component, Capturing this package will change the standard of Naming conventions. For eg: in all Microsoft applicaitons comdlg32 or any other system dll will have the same GUID.
Cheers'
Vijay