Hey guys,

I just ran into an issue here with a package.

Here's the setup:

1- Vendor supplied MSI file that was extracted from an .EXE
2- Created an MST file for that MSI using WPS 7.

Now, on Windows XP, no problems. On Windows 2000, I noticed that he created a C:\Windows folder. What was weird is that the files that are copied on C:\Windows\System32 aren't the same one that were in my package, under the Files section of Wise, under Windows\System32.

So I clicked: merge modules. I believe that my Merge Modules are hard coded to be copied in C:\Windows instead of C:\Windows or C:\Winnt. Can this be because my packaging machine where I compile is on XP? How can I solve this problem? I noticed that if I double click on each MM's, i can set a Destination Directory and a Module Source Path. However, I'm not sure if all MM's should point in my MM directory on my machine.... ???

Thanks for your help!

Stephane
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
"Your" merge modules? You mean the MMs in the MSI, correct?
Answered 05/15/2008 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

"Your" merge modules? You mean the MMs in the MSI, correct?



Yes, that's correct. I tought about editing my post on that part, wasn't clear enough. So yes, the MM's are the one's that are supplied in the vendor MSI.
Answered 05/15/2008 by: Fau
Senior Purple Belt

Please log in to comment
0
Just as I thought...Well, you have some work to do, Stephane.

IIRC, if you were to populate that default directory, then ALL the files in that MM would be installed to that location which may or may not be what you want. If it were me, I'd attempt to 'extract' the merge module from the MSI. If - as I suspect - you are using Wise Package Studio, make a back-up of the MSI then open the original MSI in WPS. It will ask you if you want to convert it to a Wise project (WSI). Choose 'Yes' and somewhere in that process - it's the 2nd or 3rd dialog - WPS will prompt you to select the embedded MM(s). You can then examine the extracted MM(s)
Answered 05/15/2008 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

Just as I thought...Well, you have some work to do, Stephane.

IIRC, if you were to populate that default directory, then ALL the files in that MM would be installed to that location which may or may not be what you want. If it were me, I'd attempt to 'extract' the merge module from the MSI. If - as I suspect - you are using Wise Package Studio, make a back-up of the MSI then open the original MSI in WPS. It will ask you if you want to convert it to a Wise project (WSI). Choose 'Yes' and somewhere in that process - it's the 2nd or 3rd dialog - WPS will prompt you to select the embedded MM(s). You can then examine the extracted MM(s)



Hello Ian,

Thanks for putting me on that track. I know what screens you mean, but I didn't get them when I opened the MSI. That said, I did get it to work by using tools/convert MSI to WSI.

So, now I have my MSM files.

What would you suggest? If it were left to me, I'd extract the files from the MSM files, an manually add them in Windows\System of my original package. If that's the solution, is there a tool to extract the files from the MSM? I quickly looked over a few pages in google, nothing really came out of the lot. I'm guessing Wise can do this....? If not, what solution would you guys propose?

Thanks again!
Answered 05/15/2008 by: Fau
Senior Purple Belt

Please log in to comment
0
OK I think I can extract the file via File, Distribute, and treat it as if it was an Administrative Installation.

So that said, is it the best method?
Answered 05/15/2008 by: Fau
Senior Purple Belt

Please log in to comment
0
First off; while "extracting" the merge module by using the convertion it will not produce the original merge module but only the referenced Module* tables so it would be impossible to "guess" the actual "data" from the MSM that was merged into the MSI.

That said it sounds like you used the InstallTailor to create the MST.
If that's the case I guess you got some hard-coded entries in the Property table replacing the Directory table entries during the CostFinalize (standard) action.

Open the MSI + MST using ORCA, entries in green in the Property table that is hard-coded to directory paths would be required to be removed which in such case should resolve the incorrect WindowsFolder "Shell Folder" path.
Directory entries are resolved to properties and Property table entries will preced "conflicting" Directory table entries meaning the same Directory.Directory and Property.Property column name.
Answered 05/15/2008 by: AngelD
Red Belt

Please log in to comment
0
File/Distribute would probably work (never used it!) but for me, this was about simply finding out the target directory for the files, rather than extracting them. If you wanted to add them to your project and the files exist in your share point's 'Merge Modules' folder, WPS will ask you if you want to substitute them with those in your MM! :)
Answered 05/16/2008 by: VBScab
Red Belt

Please log in to comment
0
Funny you should say that Ian...

What I tried yesterday was something along those lines. Instead of extracting the files from the MSM files, i just installed it on a Windows 2000 machine as is. Since it created a C:\Windows folder, i juste backed that up in my packaging folder.

I then reopened my MST file, and added these new files in Files > Windows > System under Installation Expert. As you said, it prompted me to use the Merge Modules provided, so i just unchecked the boxes. Retested.. Still getting a C:\Windows directory. I then tried simply deleting the merge modules from my MST file since I had imported them manually, and now I get some errors during the installation which I didn't have before that...

So as it stands, I'm still having problems.

I'm now going to go try Kim's solutions and see what that gives me... Hopefully something that'll work! But knowing my luck, I'm not holding my breath! I'll report back here in a few minutes.
Answered 05/16/2008 by: Fau
Senior Purple Belt

Please log in to comment
0
Wow... Kim hit it spot on...

I had two packages with the same problem, deleted all the properties with a path in them, reinstalled on Windows 2000 and *poof* no more problems on both packages!

/bow

[:D]

Thanks guys for your help again!
Answered 05/16/2008 by: Fau
Senior Purple Belt

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