A part of our product uses a service and several DLL's. For debug purposes we stop the service, replace the DLL and restart the service.
After we haved moved to MSI based setup we cannot replace the DLL's. Every time we try that we get the old version reinstalled. How can we switch that off??
Any suggestions are welcome.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Installer reinstalls files automatically
Started by
SOWI
, Jan 16 2003 16:02
7 replies to this topic
hambone
-
- Members
- 206 posts
Posted 16 January 2003 - 18:02
what operating system are you instaling to ?
if you are installing on a Win2000/WinXP platform you might be running into Windows File Protection ( WFP ), also known as System File Protection ( SFP ), issues.
if this is the case there are several good articles that will assist in getting around this...
if you are installing on a Win2000/WinXP platform you might be running into Windows File Protection ( WFP ), also known as System File Protection ( SFP ), issues.
if this is the case there are several good articles that will assist in getting around this...
SOWI
-
- Full Members
- 29 posts
Posted 17 January 2003 - 07:09
The OS is Windows 2000/XP/.NET server.
I'm surprised that the problem should be caused by the system file protection feature. I did not mark any file as system-protected file.
Would it help to remove the component key from each file??
I'm surprised that the problem should be caused by the system file protection feature. I did not mark any file as system-protected file.
Would it help to remove the component key from each file??
Frank Dering
hambone
-
- Members
- 206 posts
Posted 17 January 2003 - 14:16
i'm only saying it is a possibility...
if you look in the DLLCache directory on the target systems you will see what files are considered to be protected...
check there to see if your DLLs ( or different files with your DLL names ) are already present....
if you look in the DLLCache directory on the target systems you will see what files are considered to be protected...
check there to see if your DLLs ( or different files with your DLL names ) are already present....
SOWI
-
- Full Members
- 29 posts
Posted 17 January 2003 - 17:39
My files are NOT inside the DLL cache. So it might be an other windows installer feature.
Frank Dering
hambone
-
- Members
- 206 posts
Posted 17 January 2003 - 18:23
like i saw it's a possibility, sometimes you get lucky 
) this time we didn't (
if your files aren't conflicting with the WFP is it possible that they are conflicting with components already on the system ? ( MSISPy.EXE from MS is good at identifying what components are in a MSI and what components are on a system )
have you tried performing an ICE validation on your product ? i know it is a bit of a hassle to interpret the information and resolve the issues but it might be another place to look.
can post the ice errors encountered ( just the unique ice numbers would be a start ) ?
) this time we didn't ( if your files aren't conflicting with the WFP is it possible that they are conflicting with components already on the system ? ( MSISPy.EXE from MS is good at identifying what components are in a MSI and what components are on a system )
have you tried performing an ICE validation on your product ? i know it is a bit of a hassle to interpret the information and resolve the issues but it might be another place to look.
can post the ice errors encountered ( just the unique ice numbers would be a start ) ?
twoo
-
- Members
- 2 posts
Posted 18 January 2003 - 02:08
We had a DLL that wasn't getting updated by a MSI package. It turned out that the developers had forgotten to increment the File Version number. Even though the create date was newer, we ended up with the older version. So, we ended up turning off the Use System Attributes Check box.
Dave I
-
- Members
- 195 posts
Posted 18 January 2003 - 12:52
The repair is triggered if the file in your component is key. Good for custmoers bad for developers.
For debugging purposes locate the "features" key associated with your product in HKEY_CLASSES_ROOT\Installer\features and rename it. Then the repair wont be invoked and you can hack at will.
It should be noted that to uninstall or use your desktop shortcut you will need to restore this key to the original name.
For debugging purposes locate the "features" key associated with your product in HKEY_CLASSES_ROOT\Installer\features and rename it. Then the repair wont be invoked and you can hack at will.
It should be noted that to uninstall or use your desktop shortcut you will need to restore this key to the original name.