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.
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
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.
Answered 10/19/2011 by: jmaclaurin
Third Degree Blue Belt

Please log in to comment
0
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.
Answered 10/20/2011 by: beefy66
Orange Belt

Please log in to comment
0
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
Answered 10/20/2011 by: spartacus
Black Belt

Please log in to comment
0
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
Answered 10/20/2011 by: beefy66
Orange Belt

Please log in to comment
0
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?
Answered 10/20/2011 by: VBScab
Red Belt

Please log in to comment
0
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
Answered 10/20/2011 by: spartacus
Black Belt

Please log in to comment
0
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.
Answered 10/20/2011 by: beefy66
Orange Belt

Please log in to comment
0
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.
Answered 10/20/2011 by: jmcfadyen
Fifth Degree Black Belt

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