_Validation Table issues

[CChong]

We use a inhouse apps that uses the MSI.DLL to standardise some of our MSI's and Transforms. We have encountered a problem in transforms, when we use Tuner to generate our tranform, we have no problems, however, if we then open up the Transform in InstallShield add a file, or whatever, it doesnt matter, as long as we do a save, it does something bizarre.

What it does is that it adds the InstallShield table, which is fine, it is empty, but the problem is what it does with the _Validation table. Rather than simply adding the new entry into the _Validation table for the new InstallShield table, it deletes the entire _Validation table, and creates a new one. Any call to GenerateTransform in the MSI.DLL fails. We also use Orca 2600, and when we select the new _Validation table, Orca bombs out as well.

Essentially, once edited in InstallShield the Transform becomes 'corrupted' to all other applications that use MSI.DLL. This is a big problem for us, as ALL of our standardisation is done through our inhouse app. There is no way for us to repair this problem.

Any suggestions or help would be appreciated.

Cam.

[CChong]

How about you InstallShield guys out there? Is this a known bug? As far as I am concerned if ORCA is unable to open the MST, it does not conform to MSI Standards??!?!

Cam.

[looeee]

if you export the table to an idt file and you compare with an idt file from a clean project, are there any differences in the column definitions? (the first couple of lines)

I'm thinking that the Table is incorrectly defined. Some Microsoft merge modules have this problem.

looeee

[CChong]

With ORCA you cannot do anything to the table at all, just selecting it will bomb it out.

I can export the table from InstallShield Direct Edit, then import that table into a blank MSI using ORCA. But if I open up the same MSI+MST in ORCA, select the _Validation table, it bombs out. So I am not entirely sure how they are doing it. The are obviously not using the MSI.DLL to access an MSI, they have probably written their own API. And treat the dropping of Tables differently than ORCA does.

I am about to try dropping the table out of the Transform, saving it, then adding in my own _Validation table to attempt to repair the MST. I will add this functionality to our inhouse app.

Cam.

[TsungH]

Deleting of _Validation table and adding a new _Validation table when viewing MSI+MST is probably a result of difference in schema, say 100 and 200, between MSI and MST. The change itself shouldn't cause any problem. However, I do not know if newer schema will pose any compatibility issues to your inhouse app.

When viewing MSI+MST using Orca with default settings, Orca will terminate (at some point) when there is an error applying transform. You can suppress errors by going to Transform > Transform Properties.

There are many unknowns leading to a bad MST file. Unfortunately, it wouldn't be easy to troubleshoot without having access to any of the files (MSI, MST, and perhaps, the inhouse app) and any knowledge on AdminStudio version used to create MSI and MST. You may want to contact mySupport for assistance.

[looeee]

@Tsung
There is no difference in the _Validation Table schema between any version of MSI

@CamBooth
I want you to export the untransformed MSI's _Validation table to a file.
I am pretty sure that your original MSI has a badly defined table.

You are correct that this is a bug in InstallShield. I personally reported it in version 8 and 9.

[TsungH]

I didn't verify every column in every table to confirm there is no change in data types and sorts; but I am certain there are rows added/deleted/modified in _Validation table, which translates to changes in other tables, as MSI version progresses.

If you believe it's a bug in the product, you should submit it using mySupport.

[CChong]

I don't believe there is any difference in the table definitions between the different versions of the schema.

I only get this problem on MST's, and only after I have used InstallShield to edit it. This is the typical procedure we follow:

1. Customise the Vendor MSI by using Tuner (MST is fine)
2. Modify the MST using our inhouse app (MST is fine)
3. Open the MST up to add anything additional using Developer (MST is now corrupt)

This happens to ALL MST's regardless of schema once opened up again using Developer to add a reg key, a custom action or anything else.

There seems to be no difference in the _Validation table entries before and after, but the fact that the _Validation has the green line through it in ORCA I believe is the issue. I cannot replicate this problem using MSI.DLL, therefore it must be a problem in the InstallShield DLL's when generating the MST.

MSI.DLL generates a Transform by comparing the differences between two MSI's. So programmatically, you make a copy of your MSI, open one with read only, and the other in Transact, make the changes to the transact copy, but rather than doing a Database.Commit, we use a GenerateTransfrom(ModifiedMSI,thebackupcopy,thename of the transform) and that is how a MST is generated using ORCA, and anything else that uses MSI.DLL. As you can see, with the above description, there is no way two identical _Validation tables could exist in the MST using the MSI.DLL.

Basically I am at a loss, and am forced to discard the use of InstallShield Developer for post work on an MST, I have to add that functionality into our inhouse app, which is not what I wanted to do.

Before I modify the inhouse app, I will try and use a different MST to add the reg keys that I need, then merge the Tuner generated MST with the MST used in Developer and see if that eliminates the _Validation table issue. Perhaps a merge of a non corrupt transform will fix the corrupted transform.

Cam.

[TsungH]

I can't imagine Developer is not generating MST with APIs made available by Microsoft. The scope goes beyond the usefulness of the forum. I will suggest taking this issue to mySupport, they will be able to pull necessary resources and assist you more efficiently.