What does a verbose log say?

Is the DLL in-use?

Yes, a verbose log of the patch application would be a good starting point, as it will tell you whether the patch is working, or alternatively, why a decision has been taken not to replace the file.



Also, in your original and updated MSI files, that you used to create the patch, please check the file table and verify that the version information is correctly shown in the version column for this file. At the same time, check the MSIFileHash table and ensure there is no entry for this DLL file. What I am trying to ensure is that the MSI files have correctly extracted the version information from both the old and the new DLL, and have correctly entered it in the File table. If a version number is not extracted, then the file is assumed to be unversioned, and an MSIFileHash entry is created instead. If an MSIFileHash entry exists, as well as a file version, then something also went wrong and the filehash needs to be deleted.



Finally, make sure that the language setting of the DLL is the same, as this can also influence the success of a patch.

Hi EdT



When i was waiting for a forum response, i renamed the old dll and run the patch again.

Now the new dll file was installed, and a second modified file (txt file) was now also installed and version info in add/remove programs updated!

See the attched logfile patch1.log

Action 11:23:19: InstallFiles. Copying new files...

InstallFiles: File: EIB.dll

Directory: C:\Program Files\Priva\Top Control 6.1 Nederlands\Top Control\Drivers

Size: 1664000

InstallFiles: File: Build Versions.txt

Directory: C:\Program Files\Priva\Top Control 6.1 Nederlands\Common



Now i've uninstalled everything and start it over again:

first the MSI = OK

then a MSP = OK

then this dll MSP = NOT OK

no eib.dll installed, no buildversion.txt installed, add/remove programs not updated

See the attched logfile patch2.log

The above Copying new files... info is empty





The answers of your questions:

I can't see any decision taken in the second log ( run it with /l* ) so i've attached this



The dll is not in use

The version information is updated in the Files table (see screenhunter attachments of old and new script)

The file does not have a entry in the MSIFileHash table

The language settings in the old and new script are the same (see attachments)

Can you replace the logfiles with ZIP versions - for some reason I cannot download the .LOG versions.

Can you run the log for the situation where your patch is not applied correctly (patch2.log) using /L*v so that a verbose log is generated.

Here the log files, including the /L*v verbose version



hope you can see why EIB.DLL and BuildVersions.txt are not installed.

Are these two files in the same component? If so, which file is the key path?

The Build Version.txt file is not installed because it is unchanged in the new patch, so there is no point in installing it.

I cannot see any reason why EIB.DLL is not installed, but if it happens to be in the same component as Build Version.txt and is not the key path, then that could be the reason.

No these two files are in different components

The Eib.dll has his own component "EIB.dll1275", no further files in it.



The Build Version.txt file is also modified, and also not installed.

In this textfile i write some update information for the customer.



It's strange, that when i delete de old eib.dll, now the new eib.dll file was installed, and the Build Version.txt was now also installed and version info in add/remove programs is updated!

You can see it in the patch1.log (InstallFiles. Copying new files... )



When you don't see a solution, is it possible first to delete the dll and then run the patch?

I thought a MSP runs no custom actions

quote:
Originally posted by: WalterPriva

I thought a MSP runs no custom actions

Sure it does.

During install of the MSP the already installed package (MSI) will be reinstalled with the changes from the MSP transform(s).

I don't know how to fix this problem, you also don't have a solution for this bug? or a workarround?

I have to release this hotfix



i have tried to delete the eib.dll in my script and add again (new sequence number). The patch creation now include this dll as a new file without patch creation on previous version(s). (install in the same destination)

Also this MSP does NOT overwrite the previous version :-(



Why is the replacement option 'Always/Never/Check file' (see the WiseScript Package Editor) not available in WIS7?

quote:
Originally posted by: WalterPriva



Why is the replacement option 'Always/Never/Check file' (see the WiseScript Package Editor) not available in WIS7?

Because Wisescript was entirely developed by Wise and did not have to conform to anyone elses standards, whereas the MSI editor is unfortunately shackled by the standards imposed by Microsoft.



Did you run Upgradesync at any time? This has not been mentioned in your previous postings.

Also, the patch2 logfile shows that your text file has the same filehash in the patch as on the target system already, so that is why it is not installed. Either the text file in your package is the wrong one, or you are not testing on a clean operating system build EACH TIME.



In your update MSI, you could add a removefile operation to delete the DLL file before installing the new version, and then see if that helps with your patch generation.

Yes, i allways use the UpgradeSync from the previous version 6.1.3.7 to 6.1.3.8



(is there a maxmimum numers of hotfixes?, this is number 8 on version 6.1.3.0, 1 to 7 was no problem)



the textfile the same filehash? Why then is this file installed when i delete only de previous eib.dll?

when i do this, both file will be installed.



please can you tell me how to add a removefile operation? In Wisescript it was also easy to handle but now....

And start this operation in a small MSP? or only in a MSI?

I cannot give you an answer to your question about the text file - I can only report what the logfile said - same size, same filehash.....

The way to delete files in the Installation Expert GUI is to basically add the file in question, then look at the action drop down at the bottom of the right hand lower window, and select the delete option. This then populates the RemoveFile table rather than the file table. If you do this on a test project with just one file, you will see what format the entry appears in, in the RemoveFile table, and then you can edit your own project if your prefer, through setup editor. Once you have implemented this in the new MSI, try generating an MSP again and see if it makes any difference.



By the way, make sure that Quick compile is turned off in the Editor - or delete any existing MSI before recompiling. This ensures that your MSI does not contain any partial recompiles which can sometimes cause problems.

i made a copy of my script, marked the EIB.dll file as remove during install.

copied this entry from the RemoveFile table to the RemoveFile table in the original script and compile this.



but during the patch creation, when i select the new MSI-file at 'specify upgrade version' and press NEXT, i've an error "Internal Error 2709, RemoveFile"



I think because of in this step, the whole version is unpacked/installed in the Temp directory at local settings, and the RemoveFile cannot execute because the file does not exist in there?

So i cannot make a patch with patch creation.

Did you run an F4 table check on your updated MSI, or run ICE validation? This will give you a sanity check on the table entries before you go any further.

EdT, i'm now two day's trying to update 1 file but there is still no update of the dll and the dll will not be removed.



In the verbose, there is nothing about a removefile or addfile action for i can see.



i've some screenshots of my actions in WIS in a Word doc. attached, also the verbose



first i had the removefile and addfile in the same component: no result

then i deleted the eib.dll file and add this again, now eib.dll has his own component: also no result



i don't know what to do, custumers now call me for the hotfix

Sorry, but I have no further ideas - there is only so much that can be done without access to actual code.



If you have the Studio version, perhaps an alternative would be to write a Wisescript updater program, which deletes the EIB.DLL file, checks that it has been deleted, installs the MSP file into the temp folder, runs the MSP installation by calling MSIEXEC, and then deletes the MSP in the temp folder to clean up.

If you are certain that the EIB.DLL file can be deleted and is not "in use" when the update is being applied, then this should give you a solution you can offer to your customers.

This is not a bug, just a misunderstanding of how Microsoft's Upgrade table works.



If you look at the entries present in the Upgrade table, there are only two version fields - VersionMin and VersionMax - you can find this in the help file MSI.CHM on the topic "Updating Upgrade Table for an Upgrade".

Hence your solution of entering the minimum and maximum previous version numbers to upgrade would of course work, as that is precisely all that is required.

Had we known that you were entering multiple version numbers sooner, a solution would have been much more easily offered. However, now that you have worked it out for yourself, no doubt you will not be caught out by this next time!!

EdT, the Upgrade table contains information required during major upgrades (so i also read in the MSI.CHM)

However i dont have/need an upGrade with new upgradecode (made by a MSI), but only a small update of the same product (with a MSP)

The patch creation doesn't have to fill in the Upgrade table?



I don't understand your "Had we known that you were entering multiple version numbers sooner....."

The second step of the patch creation, ask me to add "the previous versions of the application to be updated by this patch".

Because the customer can have any version between 6130 and 6138, i read above that i must add all these previous versions of the application to be updated by this patch. Wrong??



What other solution did you had in mind ?

Why my patches works up to hotfix 7 and not with number 8 ?