Hi all,

Im under pressure to get the new build of an application packaged before the go-live date and Im trying to find ways to save time.

My idea was to apply the original mst that I built from a previous build straight onto the new msi for the vendors current build. Very little has changed that I can tell, but the application wont install. It is a response transform, and I did change a feature from install level 1 to 101.

The error message when I try this is "Error applying transforms. Verify that the specified transform paths are valid. "

I would love to be able to use my previous transform on the new build because it would save hours of work. Any suggestions would be greatly appreciated.
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
Mike - you'll probably find that when you try to apply the MST to the MSI using Orca that it will fail. This is usually because the MST adds a duplicate primary key value. For example, you may have a property called 'BOB' in your MSI, and your MST may also add a property called 'BOB'. There may also be duplicate primary key entries in the Class (Compound key), ProgId, Typelib tables etc etc. (To see the primary keys of each table consult the Windows Installer documentation)

I'm not sure how you'd find all the conflicting entries, but if you really wanted to try fudging it you could apply the MST to the MSI using InstEd. I think this way you have the option to just 'lose' incompatible changes (not ideal, I know). So now, your MST will probably apply ok during install but your install may not actually work as intended! Doh.

Really, my advice would be to just create a new response transform. Surely it will only take 15 minutes!
Answered 03/31/2009 by: captain_planet
Third Degree Brown Belt

Please log in to comment
0
I do what you're trying to do all the time. When you load the MST into your editor, do you get prompted for the location of the base MSI or not? If not, the problem is due to the MST still referring back to the original MSI. [aside] Can I remember where that reference is held? Nope...!] Rename that MSI temporarily and then load the MST. This time, you'll get prompted for the base MSI so browse to your new one and click through.
Answered 03/31/2009 by: VBScab
Red Belt

Please log in to comment
0
Thanks to you both for your advice.

I did try to rename the original msi and then apply the mst to the new msi, and it did actually work. However it turns out that the new build has changed the names of some of the files that were in the previous build and the msi cant find files it needs in the new cab file.

I could possible go through and locate which files etc are needed and where but its starting to sound too unreliable. Im just going to bite the bullet and create a new transform.
Answered 03/31/2009 by: mikej01
Yellow Belt

Please log in to comment
0
Im just going to bite the bullet and create a new transform.What tool are you using?

With WPS and IS, it'd be a snap to ditch the old files, replace them with the new and re-compile. WPS has the annoying habit of creating a new CAB in that scenario but fixing that is just a matter of aligning file sequence numbers in the Media table.

If you go the new MST route, WPS has a neat file comparison capability (Visual MSIDiff) which you could use to compare the old MST versus the new. You'd then ensure that any CAs, properties or whatever were reproduced.
Answered 04/01/2009 by: VBScab
Red Belt

Please log in to comment
0
If you want something similar to "Visual MSIDiff" but don't got WPS then you could use InstEd (www.instedit.com) instead as it has that feature too.
Answered 04/01/2009 by: AngelD
Red Belt

Please log in to comment
0
See? You really *do* learn something every day. I didn't know that!
Answered 04/01/2009 by: VBScab
Red Belt

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