/build/static/layout/Breadcrumb_cap_w.png

Merge modules screwing up in Windows 2000

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

Answers (9)

Posted by: anonymous_9363 16 years ago
Red Belt
0
"Your" merge modules? You mean the MMs in the MSI, correct?
Posted by: Fau 16 years ago
Senior Purple Belt
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.
Posted by: anonymous_9363 16 years ago
Red Belt
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)
Posted by: Fau 16 years ago
Senior Purple Belt
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!
Posted by: Fau 16 years ago
Senior Purple Belt
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?
Posted by: AngelD 16 years ago
Red Belt
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.
Posted by: anonymous_9363 16 years ago
Red Belt
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! :)
Posted by: Fau 16 years ago
Senior Purple Belt
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.
Posted by: Fau 16 years ago
Senior Purple Belt
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!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ