Software Deployment

Graeme,

without judging the process (you should really do a new version of your package and do an upgrade), don't forget that you'll have to change the entries in the media table too if you put the files uncompressed besides the msi.

so make sure the entry in the media table that corresponds to your files' sequence numbers reflects the fact they're uncompressed outside the MSI.

Also, I'm not entirely sure if changing these options and trying to use an unchanged internal CAB file will work, give it a try

EDIT: just realised maybe I misread and your initial post and you're actually building a new MSI from a project file instead of adapting an existing one... in that case I'd say just make sure you match the component GUIDs and make sure the new file versions are reflected in the file table


PJ

XSLs won't have version information so the OP will need to ensure that the files' timestamps are newer than those of th eexisting ones. A much safer route, of course, is to use the RemoveFile table to ensure that the old ones are deleted before the new ones are installed.

Guys

Thanks for the replies.

PJ, I think your original assertions were correct. I extracted an .msi which I have created a transform for. The package was tested and it was found that the 2 files I mentioned were not correct. The supplier of the software gave us 2 new files to replace the ones within the .msi. If I wanted to I could deploy the package and then copy over the new files, replacing the existing ones and the software would work fine, but I want to try and replace the files within the package so the new files go down at install time. The software has not been installed for anyone so I don't need to worry about patching existing installs.

I agree that using the RemoveFile table, as VBScab suggests, to be the best way of replacing the files. I have added the 2 files to the RemoveFile table and set the InstallMode to 3. Before adding the new files, I tested the install just to make sure the old files are being removed, but they are not. Any ideas why they wouldn't be removed at install time ?

Thanks

G

Any ideas why they wouldn't be removed at install time ?What does a verbose log show you?

I extracted an .msi which I have created a transform for. The package was tested and it was found that the 2 files I mentioned were not correct. The supplier of the software gave us 2 new files to replace the ones within the .msi.
I agree that using the RemoveFile table, as VBScab suggests, to be the best way of replacing the files. I have added the 2 files to the RemoveFile table and set the InstallMode to 3.

could you just clarify for me, are you just looking to replace the files in the msi, or is there also an upgrade of an older version of the software to be done?
If it's the first case I don't think you'll need to worry about the RemoveFile table, you just replace the files in the msi. In case number 2, you'll want to verify that the 2 packages have matching upgrade codes, and the necessary entries are present in the latest package's Upgrade Table.

PJ

Guys, thanks again for your response.

I did log the install but it doesn't seem to show much - or maybe I don't know what I am meant to be looking for. What I did find was this which related to the RemoveFiles Action.

MSI (s) (18:28) [11:38:35:156]: Doing action: RemoveFiles
Action ended 11:38:35: RemoveDuplicateFiles. Return value 1.
Action start 11:38:35: RemoveFiles.
MSI (s) (18:28) [11:38:35:156]: Doing action: ISXmlUnInstall
Action ended 11:38:35: RemoveFiles. Return value 1.

Then later in the log it has Executing op: FileCopy(...) and this is where it details the install of the file which I have added to the RemoveFiles table.

I am just looking at replacing files in the MSI. There is no upgrade of an older version.

Cheers

G

Hmmm...'Return value 1' means'Success' so it looks like the engine believes the files were removed.

Put a CA which displays a simple message before the 'InstallFiles' action and, when it appears, check whether or not the files have been deleted.

I added a CA which displays a message and when the message appeared I checked under C:\Program Files and the install folder is not there. In fact the only time I see the installation Folders and Files on the PC is after the installfinalize action.

Cheers

The supplier of the software gave us 2 new files to replace the ones within the .msi.
Tbh, I still don't get what the thing with the RemoveFile table is. Is this not just a case of modifying the existing entries in the File and Media table to change the source location of 2 files in the vendor MSI (with an MST ofcourse)? What files are there to remove? Or are you making CAs to delete the old files from the MSI and copy over the new files? Guess what I'm asking is basically if you're trying to rectify installs that are already in the field with the wrong files?

also, make sure your CA is scheduled in Deferred context after InstallFiles and before InstallFinalize, or in Immediate Context after InstallFinalize (less correct since you shouldn't make changes to the system at this point), to make sure the files you wanna remove are actually there.

Maybe I'm just confused [:(]

PJ

PJ, you are not confused, I am just being pedantic.

I have got it to work by changing the Size, Sequence and Attributes within the Files table for the existing entries and then adding an extra line into the media table (all in an .mst). In fact that is what I originally did but when I read other posts regarding the RemoveFiles table, I thought I would give the RemoveFiles a go as well. When the RemoveFiles didn't work I was intrigued as to why. Since it is turning into a bit of a ball ache and I need to get this done, I am going to go with what works.

Cheers for the help guys.

Graeme

aha,

well, nothing wrong with being curious. I must have missed the part where this was no longer about the core issue with your package, but no worries [;)]

PJ

Pieter, "the thing with the RemoveFile table is" that the OP wanted to replace files which don't have version information. By far and way the most reliable way to do that is to remove the existing files before the new ones get installed. Yes, you can faff about with timestamps, companion files and all that but, it's a gazillion times easier to simply vape them before you begin.

By far and way the most reliable way to do that is to remove the existing files before the new ones get installed. Yes, you can faff about with timestamps, companion files and all that but, it's a gazillion times easier to simply vape them before you begin.

but if you're working with the (vendor) MSI that you'll be doing the installs with, why not simply REPLACE the entries for the incorrect files (File Table / Media Table) in the MSI with the new versions, and forget all about the old versions?? (that is if you haven't got any installs out in the field and you can make a clean start)