Validation Inconsistency
Hi,
Kind of a trivial one, but hping someone can shed some light on this for me:
I have created a transform on an .msi. All is working ok, but when I run validation I get slightly different errors. If I run validation on the msi i get the error:
ICE30 ERROR The target file 'Q_INSA~1.QRP|q_insaddress.qrp' is installed in '[ProgramFilesFolder]\Agfa\RIS\Programs\' by two different components on an LFN system: 'Printserver_Be_qrp' and 'Printserver_Int_qrp'. This breaks component reference counting.
If I run validation on the transform I get:
ICE30 ERROR The target file 'Q_INSA~1.QRP|q_insaddress.qrp' is installed in 'C:\Program Files\Agfa\RIS\Programs\' by two different components on an LFN system: 'Printserver_Be_qrp' and 'Printserver_Int_qrp'. This breaks component reference counting.
Why is it than the .msi is using properties, but the transform is expanding them to the full path? When we check for ICE errors we use windiff to compare the entries, so these 2 errors show as being different from each other in my results.
Thanks in Advance,
Beefy.
Kind of a trivial one, but hping someone can shed some light on this for me:
I have created a transform on an .msi. All is working ok, but when I run validation I get slightly different errors. If I run validation on the msi i get the error:
ICE30 ERROR The target file 'Q_INSA~1.QRP|q_insaddress.qrp' is installed in '[ProgramFilesFolder]\Agfa\RIS\Programs\' by two different components on an LFN system: 'Printserver_Be_qrp' and 'Printserver_Int_qrp'. This breaks component reference counting.
If I run validation on the transform I get:
ICE30 ERROR The target file 'Q_INSA~1.QRP|q_insaddress.qrp' is installed in 'C:\Program Files\Agfa\RIS\Programs\' by two different components on an LFN system: 'Printserver_Be_qrp' and 'Printserver_Int_qrp'. This breaks component reference counting.
Why is it than the .msi is using properties, but the transform is expanding them to the full path? When we check for ICE errors we use windiff to compare the entries, so these 2 errors show as being different from each other in my results.
Thanks in Advance,
Beefy.
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
jmaclaurin
13 years ago
If I had to guess, I would say its because the mst was created as a recording and subsequently it took the resulted value which you could (maybe should) set back to the original property.
Posted by:
beefy66
13 years ago
The mst was created via a script by the original .msi, but when I have checked the component and directory tables, the corresponding columns are exactly the same. They are both using the properties and not hard coded paths.
Posted by:
spartacus
13 years ago
Something to try out might be to open the base MSI in ORCA, apply the transform then do a 'Save Transformed As.." saving the transformed MSI under a different name. Then perform validation on the transformed MSI and see what ICE30 reports under those circumstances ?
Spartacus
Spartacus
Posted by:
beefy66
13 years ago
spartacus, I have tried what you suggested, and the ice30's show the fully equated path in this scenario. Its the original .msi only that shows the properties in the ice30's rather than the paths
Posted by:
anonymous_9363
13 years ago
Clearly, then, the engine (new word I invented) hard-resolves the paths when processing transforms but soft-resolves them when processing the MSI. My guess would be that it has to, in case the transform changes anything of relevance in the MSI's tables, such as directories. Does it matter?
Posted by:
spartacus
13 years ago
ORIGINAL: VBScab
Clearly, then, the engine (new word I invented) hard-resolves the paths when processing transforms but soft-resolves them when processing the MSI. My guess would be that it has to, in case the transform changes anything of relevance in the MSI's tables, such as directories. Does it matter?
I can see the reason why it should matter as it sounds like the OP is using windiff to compare validation output from a base (vendor) MSi and validation from the same MSI with a transform they have created to determine whether any changes made by the transform has introduced any additional ICE errors/warnings which need to be addressed.
In my own experience its often the policy that any ICE errors/warnings related to the vendors original MSI are left alone, but additional ones introduced by customisation through transforms should be resolved.
Spartacus
Posted by:
beefy66
13 years ago
exactly right spartacus. Because the ouput is different these will be flagged as different errors in our processess. This is the first application I have done which has exhibited this sort of behaviour.
Posted by:
jmcfadyen
13 years ago
I have recently been dealing with the same apps (poor you) hehe
Actually agfa have quite good packagers for a vendor. But the spastic paths in the first instance are the result of installshields inadequate method of dealing with file paths. the latter i believe comes from the script from memory this script was vbs post it in here I can't recall what it was doing off hand.
Actually agfa have quite good packagers for a vendor. But the spastic paths in the first instance are the result of installshields inadequate method of dealing with file paths. the latter i believe comes from the script from memory this script was vbs post it in here I can't recall what it was doing off hand.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.