Key file of a component is not installed
Hi all,
Hope someone can help me with this strange issue that i face...
The key file of a component, the only file in that component (which actually comes from a merge module) is not getting installed on the initial installation but gets installed on repair. [:@]
Actually a copy of the same file(a different, higher, unwanted version) is already present in the target machine. But that has to be replaced with a lower version of that file through my application. So i have included a script to delete that file before the installation starts. That file is getting deleted actually but my desired file is not getting installed as i said earlier(but gets installed on repair).
The log files states this:
If i manually delete the file first and then go on with installation, the file gets installed. [&:] And in this case i can see the value for SharedDllRefCount as 1. So i started working on "SharedDllRefCount". I deleted the registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
] before the installtion but still no success. So can can anyone help me in knowing where the value of SharedDllRefCount is picked from during the installtion. Or if i am going on a wrong track please help me out....
Hope someone can help me with this strange issue that i face...
The key file of a component, the only file in that component (which actually comes from a merge module) is not getting installed on the initial installation but gets installed on repair. [:@]
Actually a copy of the same file(a different, higher, unwanted version) is already present in the target machine. But that has to be replaced with a lower version of that file through my application. So i have included a script to delete that file before the installation starts. That file is getting deleted actually but my desired file is not getting installed as i said earlier(but gets installed on repair).
The log files states this:
MSI (s) (BC:74) [16:57:09:076]: Executing op: ComponentRegister(ComponentId={D608F140-DCEA-4455-A1D2-76A30431F5D6},KeyPath=C:\Program Files\Microsoft ActiveSync\richink.dll,State=3,,Disk=1,SharedDllRefCount=2,BinaryType=0)
1: {901F0409-6000-11D3-8CFE-0150048383C9} 2: {D608F140-DCEA-4455-A1D2-76A30431F5D6} 3: C:\Program Files\Microsoft ActiveSync\richink.dll
If i manually delete the file first and then go on with installation, the file gets installed. [&:] And in this case i can see the value for SharedDllRefCount as 1. So i started working on "SharedDllRefCount". I deleted the registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
] before the installtion but still no success. So can can anyone help me in knowing where the value of SharedDllRefCount is picked from during the installtion. Or if i am going on a wrong track please help me out....
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
Inabus
15 years ago
In its default state MSI wont allow you to downgrade files like that as it knows they are older files.
Also DLL reference counting is there to stop a file being removed until its count is 0, as its 2 it shows that 2 applications use that DLL so it wont be uninstalled until the count = 0.
Why do you need to downgrade anyway, doesnt the app work with the newer file?
P
Also DLL reference counting is there to stop a file being removed until its count is 0, as its 2 it shows that 2 applications use that DLL so it wont be uninstalled until the count = 0.
Why do you need to downgrade anyway, doesnt the app work with the newer file?
P
Posted by:
rayz_0020
15 years ago
Hi.. Thanks for the response...
I can understand that the files can't be downgraded, the reason why i have included a script before the installation starts, as i have mentioned earlier. And also this application doesnt work with the higher version. [:@] In fact, it is stated as an important requirement for this app.
Actually the file gets deleted(becuase of the script), but my problem is that the file available in my app is not getting installed and that too only on initial install as i have said. So hw can i to handle this???
I can understand that the files can't be downgraded, the reason why i have included a script before the installation starts, as i have mentioned earlier. And also this application doesnt work with the higher version. [:@] In fact, it is stated as an important requirement for this app.
Also DLL reference counting is there to stop a file being removed until its count is 0, as its 2 it shows that 2 applications use that DLL so it wont be uninstalled until the count = 0.
Actually the file gets deleted(becuase of the script), but my problem is that the file available in my app is not getting installed and that too only on initial install as i have said. So hw can i to handle this???
Posted by:
anonymous_9363
15 years ago
What does the log tell you at the stage where WI is 'deciding' what to install, i.e. where you get the line similar to
MSI (s) (40:A4): Component: DodgyComponent; Installed: Absent; Request: Local; Action: Local
Posted by:
rayz_0020
15 years ago
MSI (s) (48:20) [16:22:02:071]: Component: richink.dll.F0588CE8_7B2E_413B_9211_EDBB19304362; Installed: Absent; Request: Local; Action: Null
Posted by:
Inabus
15 years ago
If all your doing is deleting the file then it may be down to the reference counting key thats blocking the older file being installed. The issue here is that other applications use this file, as noted by the 2 in your count, so the question should be do these other apps work with the older version?
Also im assuming that the app installs on a clean machine?
Also im assuming that the app installs on a clean machine?
Posted by:
anonymous_9363
15 years ago
While I mull this over, I'd make the point that I'd be extremely cautious about an app steaming in and changing a file installed by a completely different app, especially downgrading it. As Paul (Inabus) alludes, I presume the older version has been tested - to user's satisfaction - with the other apps which use it?
Posted by:
turbokitty
15 years ago
What packaging tool are you using?
I haven't used Wise in awhile, but in Installshield, you can override the version number of the dll so that it always overwrites existing ones.
I agree with the guys above, you should really find out what app is using that newer dll before you go and replace it.
If you're repackaging, you can try localizing the dll to the install directory.
I haven't used Wise in awhile, but in Installshield, you can override the version number of the dll so that it always overwrites existing ones.
I agree with the guys above, you should really find out what app is using that newer dll before you go and replace it.
If you're repackaging, you can try localizing the dll to the install directory.
Posted by:
AngelD
15 years ago
You should be able to "downgrade" if you for example remove the file first using the RemoveFile table or you could just add it as a DuplicateFile.
Posted by:
jmcfadyen
15 years ago
sounds to me like in this instance you would be better off isolating the file to the local application folder.
on another note for interests sake there is two types of reference count.
SharedDllReference count and component reference count. (the latter of which is windows installer based)
on another note for interests sake there is two types of reference count.
SharedDllReference count and component reference count. (the latter of which is windows installer based)
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.