Share via

MSI Install-On-Demand

  • Article

According to MSDN documentation How the Runtime Locates Assemblies, if fusion can’t find the assembly through probing, fusion will ask Windows Installer to provide the assembly if Windows Installer has information about the assembly.

<quote>

Probes for the assembly using the heuristics described in the probing section. If the assembly is not found after probing, the runtime requests the Windows Installer to provide the assembly. This acts as an install-on-demand feature.

</quote>

Alan talked about the Install-On-Demand in his blog back in Nov 2003.
https://blogs.gotdotnet.com/alanshi/PermaLink.aspx/a37d41c6-fc0a-4704-a024-42ecbc5db807

I don’t want to repeat what has been said. Here I want to talk about the details of MSI Install-On-Demand.

Install-On-Demand is per assembly. This means Install-On-Demand will be invoked for every assembly probing failure.

For Install-On-Demand there are two contexts. One is global context, which responds to all the assemblies installed to GAC. Another is application qualified context. Each assembly either belongs to the global context, or to an application context.

At runtime when fusion looks for Install-On-Demand information, fusion will look at the global context, as well as the context of the currently running application.

The context is really an MSI concept.

Over the years I have received several questions about this feature. Apparently it is used by people.

And John Lyon-Smith even opened a bug on MSDN feedback center!
https://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=6ca1cd8c-4cc4-4456-8c50-7705b5157548

John’s scenario does not work. It is not because fusion does not invoke Install-On-Demand, but because the assembly in question is in the wrong context.

Specifically, John is using VS to develop an MSI package. The package has two assemblies, Binding.exe and ClassLibrary1.dll, both built by VS. After the package is installed, if ClassLibrary1.dll is removed, it will not bring back by MSI Install-On-Demand.

The reason is when VS builds the package, VS puts Binding.exe and ClassLibrary1.dll into different contexts. In other words, Binding.exe is in Binding.exe context, and ClassLibrary1.dll is in ClassLibrary1.dll context.

At runtime when fusion is asked to find ClassLibrary1.dll, since Binding.exe is the currently running application, fusion will look for ClassLibrary1.dll in the Binding.exe context, and won’t find it there.

The reason VS puts them into separate contexts is that VS has no idea about the relationship between these two assemblies. For VS, all assemblies are equal. If VS had a feature to (manually) assign assemblies to different context, then this bug could be fixed.

According to the comment on the bug, the assigning assemblies to different context feature is resolved by won’t fix by VS team. If you want to build a MSI package with Install-On-Demand feature, you will have to find alternatives.

(I am very sure that context is not the right terminology here. But I am not familiar with MSI so I hijacked the term context.)

Comments