danielbcn
21st May 2009 13:07 UTC

Cannot overwrite dll files in system32
Hi,

I am pretty new to NSIS. I am facing a problem that I'm sure must have a simple solution.

Everything works fine when I install my application for the first time in a PC.

Then, I unistall it and then I want to reinstall it back. I get no errors from the setup program, but the DLL's I had copied to windows\system32 folder are never overwritten. For some reason, the only way to get the new version installed is to delete manually the old dlls first.

This happens either in Windows XP or Windows Vista, no matter if the user has administrator rights or not.

Do you know if there is any instruction that can overcome this limitation?

I'm sending the whole script so you can see what I'm doing.

Thanks in advance,

Dani Carbonell

danielbcn
3rd June 2009 12:18 UTC

Things I've tried
In UpgradeDLL.nsh, I tried to change

SetOverwrite try

to

SetOverwrite on

... thinking that was going to be it... but it still won't overwrite the files...

Any other ideas?

Thanks!

jpderuiter
3rd June 2009 17:22 UTC

Why don't you delete the DLL files when uninstalling?
Or are these DLL's shared?

You can try the InstallLib macro which is included in NSIS.
Search the NSIS manual for InstallLib for more info.

Afrow UK
3rd June 2009 17:24 UTC

It may be that the files have attributes set. Try SetFileAttributes dll_file.dll NORMAL

Stu

redxii
3rd June 2009 21:15 UTC

Are you trying to overwrite Windows system files? It looks like it. If the files need to be updated you should bundle a redistributable setup from Microsoft with the updated DLLs and have your script execute it, or put the files in the same folder as your program. You should not be replacing system files with your own, Microsoft prevents it and developers replacing system file with their own was the reason users experience instability with Windows or other applications.

Simon Brown
3rd June 2009 21:19 UTC

Re: Cannot overwrite dll files in system32

I get no errors from the setup program, but the DLL's I had copied to windows\system32 folder are never overwritten. For some reason, the only way to get the new version installed is to delete manually the old dlls first.

Programs expect to be able to overwrite the files. A program's setup would run and it decided that it needed to "update" some system file and attempt to overwrite it. If the system tried to stop the file from being overwritten, the setup program would halt and report that it was unable to install the file. Even if the operating system detected that somebody was trying to overwrite a system file and instead gave them a handle to NUL, those programs would nevertheless notice that they had been hoodwinked because as a "verification" step, they would open the file they had just copied and compare it against the "master copy" on the installation CD. The solution was to let the program think it had won, and then, when it wasn't looking, put the original back.

redxii
3rd June 2009 21:56 UTC

Since you're updating VB6 runtimes you should use this setup instead, either indicate it needs to be installed first or extract it to $TEMP or $PLUGINSDIR run it from your setup: www.microsoft.com/downloads/details.aspx?FamilyId=7B9BA261-7A9C-43E7-9117-F673077FFB3C&displaylang=en but you shouldn't install it for XP and later. Although it wouldn't hurt because Windows should make sure newer versions aren't overwritten with older ones.

danielbcn
4th June 2009 06:13 UTC

In response to some of the comments:

- Why don't you delete the DLL files when uninstalling?
Or are these DLL's shared?

They are (potentially) shared among a few aplications.

- It may be that the files have attributes set.

Do you mean they are marked as read-only? If so, they are not (I just checked).

- Are you trying to overwrite Windows system files?

I'm not overwriting the system files, but some dlls I developed which are shared among some applications I have developed.

- Programs expect to be able to overwrite the files.

You mean Windows makes the setup program think it has been able to overwrite the files and then, when it is not looking, goes back to the old version? Do you think there is a way to avoid this to happen?

- Since you're updating VB6 runtimes you should use another setup instead.

The problem I get os with my custom DLLs, not with the system ones.

Thanks everyone for your replies.

Dani

Afrow UK
4th June 2009 11:55 UTC

Files with SYSTEM set are not always overwriteable in my experience.

Stu

danielbcn
4th June 2009 13:16 UTC

Hi, Afrow UK,

Thanks for your comment.

The files I need to overwrite do not have the SYSTEM attribute, they are regular dlls.