Software Deployment

Screnario A (Installing Component with same GUID and file to Same location )
Apps A
Componet C-A1 = "{0F794AC3-F266-4238-BC59-4AD641DD5F8F}"
File ( ABC.DLL / Version 1.0 / Keyfile )

Apps B
Component C-B1 = "{0F794AC3-F266-4238-BC59-4AD641DD5F8F}"
File ( ABC.DLL / Version 1.2 / Keyfile )
If these two apps installed in the same machines (AppsB after AppsA), Is it true
that i say statement below ?
1. Component Count "{0F794AC3-F266-4238-BC59-4AD641DD5F8F}" = 2
2. File ABC.DLL SharedDLL's count = 2
3. File ABC.DLL ( Version 1.2 remain )
4. If AppsA being run but with backward compatibility issues, self healing will
triggers to reinstall ABC.DLL version 1.0


The version 1.0 dll will not be replaced on repair scenario's under default conditions. The REINSTALLMODE property is checked and versioning rules would apply based on that setting. In default setup OMUS or VOMUS settings are likely which in turn means that the file would never downgrade to a previous version.

If you think about Component reference, essentially its easy to refer to it as a count however in actual fact is a client (Product) registered against that Component.

For example Component C-B1 would register application B1 against that component. (known as a client) when you uninstall a product that product removes its client registration from each component. Its often incorrectly referred as reference counting as thats the easiest way to explain it (as a count).

The shared dll count is an attribute of a component (i think from memory its 8 or 16) I don't do this too often any more so I am getting a little rusty. It is unrelated to component reference counting however it does perform a similar task.

Another point is it is a good idea to maintain the component names as well C-A1 C-B1 should be the same as well not many conflict managers deal with this. (if any). Rob Mensching has a good article on why this should be done.


Screnario B (Installing Component with same GUID and file to different location)
Apps A
Componet C-A1 = "{0F794AC3-F266-4238-BC59-4AD641DD5F8F}"
File ( ABC.DLL / Version 1.0 / Keyfile )

Apps B
Component C-B1 = "{0F794AC3-F266-4238-BC59-4AD641DD5F8F}"
File ( ABC.DLL / Version 1.2 / Keyfile )
If these two apps installed in the same machines (AppsB after AppsA), Is it true
that i say statement below ?
1. Component Count "{0F794AC3-F266-4238-BC59-4AD641DD5F8F}" = 2
2. File ABC.DLL SharedDLL's count = 2
3. File ABC.DLL ( Version 1.2 remain )
4. File ABC.DLL ( Version 1.1 installed )

This is an interesting situation, the rules used to state that we should never do this. I have however noticed that Wise doco states it doesnt do this, yet in practice is actually does match in different folders. (this changed in version 6.0)

I recall having a large discussion about this some years back when this all came about, I believe in the end the group decided that it is not necessarily a bad thing to match components in different folders. It would be interesting to hear other peoples thoughts on this.

I would however like to mention when you have COM components in folders like this you should not register them in multiple locations. I think if your using wise its less of an issue to match across components, but with installshield you could run into some issues.

My reasoning lies in the component structure of Wise vs Installshield packages.

Wise tends to bundle COM into the same component as the actual COM resource where as Installshield splits the two into different components. Which I think is a terrible idea and one of the core reasons I can't stand IS. (sorry you have it)

This essentially means that you can uninstall one without the other. To alleviate this issue on IS there is an option to leave all registry components installed at uninstall. Which is untidy but somewhat safer.

You are delving into a world of hurt, which is rather interesting. I am more than happy to pitch in where I can as I follow this topic with alot of interest

Hi guru,

I've been reading Rob Mensching back and forth few times trying to understand more on Windows Installer. I've some doubts on what's written in the article http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101 typically on his explanation "Different Component GUID's but same File(Resource)". He explained :-

Two Apps below :-
Apps A - C1 {0F794AC3-F266-4238-BC59-4AD641DD5F8F} = { A.DLL }

Apps B - C2 {5B2390D5-C8D0-43b0-980F-01A872E809C4} = { A.DLL }

After Installation Component Count
C1 {0F794AC3-F266-4238-BC59-4AD641DD5F8F} = 1
C2 {5B2390D5-C8D0-43b0-980F-01A872E809C4} = 1
A.DLL = 1 ( Is this true? If i were to set Shared = Yes ) , I would have Count = 2 right?
If my theory is correct, there could be something wrongwith his explanation in the blog. Hmmm.. things really gets so confusing ...

hi mate,

As much as I value Rob's idea's I never take anything at face value and tend to prove these things myself.

So rather than tell you what will happen I will tell you how you can prove it which then you can tell for sure what will happen without the need for someone like myself to tell you something which may or may not be true.

on my blog is an entry on component reference counting read that then you will be able to follow the component client counts yourself.

http://johnmcfadyen.spaces.live.com

as for the shared dll counter

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls

Run up both your msi's and read the counts yourself.

Whatever happens is your answer. I do however agree you would be right if shared dll counters are set the count would be 2 ..

One thing which I think you may be missing however, is COM dll's are nothing without the associated registry. So the shareddll counter is potentially not entirely accurate as you may be able to keep the dll on the machine but not the registry (depending on the packaging tools you use and how accurately you check that packaging)

I will read Rob's post again and see if i can pickup on his suggested error. Even Rob could fail to be correct, also note some of his doco was written years and years ago.

Hi John,

Thanks for the invaluable explanations. Hope that you could see something different from me in Rob's blog. I'm still searching for some good reading material on WinInstall. :)

I'm still searching for some good reading material on WinInstall. :)Look no further than your invoice for Wise Package Studio.