PackageAware capture problem

[RM]

Hi,

I captured a setup with packageaware (taken from installaware 6 directory) from a virtual machine (VMWare) and then copied it on my host machine to open the .mpr file with installaware. Once the project is opened, just noting shows up, (the refactor path dialog is all greyed out too). Checks were made on the mia, dfm etc file generated, and it appears that many files have 0 kb in size, especially the "main" mia file (in my case mozilla thunderbird.mia).
Here is the result of the capture:

32.756 destination.dfm
0 destination.dfm.miaf
161.047 finish.dfm
1.490 finish.dfm.miaf
32.086 licensecheck.dfm
128 licensecheck.dfm.miaf
160.192 maintenance.dfm
0 maintenance.dfm.miaf
0 mozilla thunderbird.mia
290 mozilla thunderbird.mia.fld
1.981 mozilla thunderbird.mpr
32.211 prereq.dfm
370 prereq.dfm.miaf
43.052 progress.dfm
292 progress.dfm.miaf
42.687 progressprereq.dfm
0 progressprereq.dfm.miaf
31.936 readme.dfm
128 readme.dfm.miaf
159.671 startinstallation.dfm
0 startinstallation.dfm.miaf
32.908 startmenu.dfm
228 startmenu.dfm.miaf
159.591 welcome.dfm
0 welcome.dfm.miaf

An other person did the same kind of capture (probably with another packageaware version) and had the following results (notice mozilla thunderbird.mia size is different from zero):

32.756 destination.dfm
0 destination.dfm.miaf
161.047 finish.dfm
1.490 finish.dfm.miaf
6.426 LICENSE.txt
32.086 licensecheck.dfm
128 licensecheck.dfm.miaf
160.192 maintenance.dfm
0 maintenance.dfm.miaf
412.160 mMSIExec.dll
188.513 mozilla thunderbird.mia
188.513 mozilla thunderbird.mia.bak
898 mozilla thunderbird.mia.brk
127 mozilla thunderbird.mia.fld
2.013 Mozilla Thunderbird.mpr
2.013 mozilla thunderbird.mpr.bak
385.536 mWinRunExec.dll
32.211 prereq.dfm
370 prereq.dfm.miaf
43.060 progress.dfm
292 progress.dfm.miaf
42.696 progressprereq.dfm
0 progressprereq.dfm.miaf
<REP> Release
159.671 startinstallation.dfm
0 startinstallation.dfm.miaf
32.340 startmenu.dfm
228 startmenu.dfm.miaf
159.591 welcome.dfm
0 welcome.dfm.miaf

I guess the the problem comes from packageaware (i'll try another version)... Any idea what is causing this problem ?

Thanks

[MichaelNesmith]

Can you provide more details on this incident? What Windows version was the VMware running? A link for the file that you were capturing? Did you have admin rights on the VMware machine? Can your colleague try with your same copy of PackageAware and let us know if it works on his system?

Thanks!

[RM]

Version on VMWare is Windows XP Pro SP2 (version 2002).
All the operations were done using an admin account.


I was curious and tested to do a base scan, install nothing and then calculate the delta: it seems the result is almost the same (1kb more, 1 kb less) as when i did de delta after installing firebird. (maybe the problem comes from the registry: packageaware not working on the rigth user ?; or maybe a bug in VMWare reading the registry information from the snapshot and not from the RAM where the latest registry version is located ?)

Link for the file I was capturing: mozilla firebird 1.5.0.4 (french)downloaded at:
http://frenchmozilla.sourceforge.net/

I'll ask my colleague to try with my packageawre (He's using virtual pc though, not VMWare)

Thanks

[ymajoros]

I'm the colleague... Just a few remarks...

There can't be a bug concerning VMWare reading the registry, as VMWare doesn't even know about that (and shouldn't)... VMWare is emulating a PC, only the Windows OS you install on it is having knowledge of the registry. Also, most (if not all) registry changes should be in HKLM, so they are not user-dependant and I don't think this is the problem.

I did everything with InstallAware 5, a few months ago. PackageAware did work then. The version of PackageAware which is in InstallAware 6 seems to be almost the same (a few hundred bytes more). It seems to generate about the same files, too, but there is one ("mozilla thunderbird.mia") which is 0 bytes in size in the new version (could that be the problem?).

[RM]

Hi again,

I just tried a capture (with packageaware from installaware 6) on my host computer: Looks like it's working: the mozilla thunderbird.mia is no more 0kb: its 93kb.

The project is opened correctly with installaware (refactor path dialog availables etc, all ok).

The delta calculation took more time than on the VM.

When saving the project after the scan, it suggests the name thunderbird.mpr, not VMWare.mpr like it did in the VM.

(the host machine is also a winXP sp2 ver2002)

[ymajoros]

Could the space in the original project name ("Mozilla Thunderbird") confuse PackageAware?

[MichaelNesmith]

Thank you very much for the great feedback, guys.
I don't think the space can be a problem, because one of you reports a successful capture, even with the space. I will now download and try this myself, to see what I can find.
Thanks again - will post back here as soon as I know more.

[ymajoros]

I don't think the space can be a problem, because one of you reports a successful capture, even with the space.

Yes, but with a previous version.

[MichaelNesmith]

Are you sure - revisit RMs most recent post...he says he used v6.

[MichaelNesmith]

I was able to successfully perform the capture. I used a Windows XP Service Pack 2 machine to capture the French installation. I've attached the captured project in a ZIP file for your convenience.

This is with PAv6.

File Attached:

mozilla thunderbird.zip

[RM]

Hi everyone,

I figured out what was the problem,

I had on my VMWare a shared folder (with my host computer) I mapped as a network drive.

When clicking the finish button of PackageAware, you are asked to select a path to save the files to. I always selected that shared folder (and had the bad results). Now i tried to save the files on the local VM HDD and everything is fine. (I copied it later manually to the host machine and opened it with InstallAware 6 : everything is ok).

So what's the problem ? I guess PackageAware, when saving the files first creates a 0kb file and then modify it to end with the complete file. VMWare shared folder doesn't looks to appreciate that. However, things doesn't really add up with that theory: there are no error messages (write access denied, etc), besides, not all files are 0kb, thing that should logically happen in that case....

Anyway, thanks for the help and sorry for the inconvenience.

[ymajoros]

Congratulations, that was not so easy to find out. Sorry you lost so much time with that, and I hope this will be fixed in future versions.

For information, I did the same procedure in Virtual PC and didn't have the problem, but it seems the shared folders are different in VMWare (I think they behave more like network drives).

I guess it would be good if someone from the InstallAware team could reproduce and document the problem, too.

[MichaelNesmith]

Thanks everybody for the diligence in sorting this one out!

VMware's shared folders implementation is quite problematic. For instance, try putting an MSI package there (any MSI package - not necessarily one created with InstallAware). Its installation will fail, with an obtuse error.

For this reason, we recommend using real network shares, substituted network drives, or just drag-drop when working with VMware. Shared folders sometimes work, and sometimes don't - not just with InstallAware, but in our experience, with most types of applications - some subtle things tend to go wrong.