install not replacing old DLLs

[adrien]

I've got an install which refuses to replace old DLLs.

e.g. I install a new version of our product over the top of an old one, and it doesn't replace or overwrite the DLLs of the old version.

The files in the project are set to replace older versions (I wish there was an option for replace if the file version in the ver info resource was lower). Anyway I wonder if it's something to do with...

When I look in the project, it shows me the included files, and has dates in there as well. These dates are the dates of the files that were originally added to the project (surely this is bogus, it should know the date on the file when it takes the actual files when it builds the actual project). The file path includes a session variable set by our build process, so all the files show as "missing".

I'm wondering if when the installer is built it's not picking up the correct date of the files it is adding to the installer when it does that, so thinks the files in the installer are older than on the disk.

In any case - does anyone know how to get it to replace the files?

[jassing]

I've got an install which refuses to replace old DLLs.

e.g. I install a new version of our product over the top of an old one, and it doesn't replace or overwrite the DLLs of the old version.

The files in the project are set to replace older versions (I wish there was an option for replace if the file version in the ver info resource was lower). Anyway I wonder if it's something to do with...

When I look in the project, it shows me the included files, and has dates in there as well. These dates are the dates of the files that were originally added to the project (surely this is bogus, it should know the date on the file when it takes the actual files when it builds the actual project). The file path includes a session variable set by our build process, so all the files show as "missing".

I'm wondering if when the installer is built it's not picking up the correct date of the files it is adding to the installer when it does that, so thinks the files in the installer are older than on the disk.

In any case - does anyone know how to get it to replace the files?

As I understand it "replace older" really does two comparisions as needed..
1) If there are file versions in BOTH target & source, the version is used to determine "older" status
2) if one or both doe snot have a version; then last-modified date is used.

What is the setting for "Supress In Use" checkbox? (checked or not) for the files in question?
Have you examined the resulting install log?

[adrien]

Hi

Thanks for your response.

That setting is unchecked for all files. I'll need to check the logs.

[jassing]

And this is an installer that you're running -- so you know you're not hitting "skip" or something (ie: not a user-report)

be sure your logging is set to "Extended Errors" just in case.....

[adrien]

Hi

It's just running through. I just tried an install, and all the file copies were marked as "Skipped" with reason "Existing file overwrite setting".

Seems bogus to me. All these files have version info settings and the auto-incrementing build number is stamped into all the DLLs, so the version number should make it replace, as should the last modified date etc.

[adrien]

p.s. when I look at the properties of the file in SF7, and click on the "Details" button on the General tab, nothing happens.

I'm really suspicious it's something to do with all the files in the project showing as "missing".

[Ulrich]

I'm really suspicious it's something to do with all the files in the project showing as "missing".

So you are saying that the dlls you are trying to bundle into your installer to overwrite those the current installation are marked as missing? Yeah, that may "probably" be the motive why the current files aren't updated. I hope that you are kidding...

Ulrich

[adrien]

I'm not kidding. The files are marked as missing because they are in a folder that contains a session variable (Local folder contains a session variable), so only at build time does the path in the project resolve to a real correct path. E.g.

#LOCALFOLDER#\Installs\Template\WinGate

I did some more testing. If I select "always overwrite existing file", it replaces the file. If I select "Overwrite if existing file is same or older" it replaces it, but if I select "Overwrite if existing file is older" then it skips, even though the file it should be replacing has an earlier date stamp and a lower version number.

So looks to me like a bug in SF.

[adrien]

any ideas? Or should I raise this as a support ticket?

[jassing]

any ideas? Or should I raise this as a support ticket?

W/o the SF7 file and dll's in question; I have no ideas...
Raising a support ticket would likely not do much good -- get he SUF8 eval & replicate.. THEN raise the issue

[adrien]

I have a licensed version of SF8 already - just haven't moved everything over to it.

Reason we use session variables in paths is so we don't have to do all our installer development on the build machine.

[jassing]

I have a licensed version of SF8 already - just haven't moved everything over to it.

Just open up the .sf7 file in sf8 -- 100% conversion.....

Reason we use session variables in paths is so we don't have to do all our installer development on the build machine.

I have no idea what that means..... session vars are not machine specific....

[adrien]

session vars aren't, but paths are (directory structures etc).

So when I open the project in any SF editor, the files show as missing because the session variable isn't set. It's only when we run the build that it provides the variable.

[Ulrich]

IMO, you should map those folders (like #LOCALFOLDER#\Installs\Template\WinGate) properly on your local network. Then the inclusion of the files in those shared/mapped folders in the project wouldn't cause any problems, as SUF would be able to gather the file and version infos correctly at the start of the build, and they wouldn't show up as missing in the IDE. And by doing so, the installer could be built on any machine on the network.

I was told that the code for version 7.0 is frozen, and no further modification will be made.

Ulrich

[adrien]

OK

I migrated our build server to SF8, and did a build. Took a lot longer to generate the installer, but about 25% smaller, so can live with that.

Anyway - same behaviour. I'm not surprised, since I doubt the code that evaluates whether to replace a file or not has been touched in years.

I tested various things. including whether the file was signed or not (no difference). I'm pretty much convinced it's to do with the session variable.

All I can suggest is this be expicitly tested there - should take about 5 minutes. We use a settings file to specify the variables.

Otherwise if I'm to get rid of that sesson variable, I'll have a major issue whenever editing the file on my local machine. Will basically be forced to either

a) replicate the entire directory structure of the build machine onto my dev machine
b) do all the installer dev on the build machine
c) try and get this bug (?) addressed.