This is the response I recieved in email from Amber Aggerwal from Installshield, and I think it does an excellent job at giving a very detailed explanation of whats going on. Posted here with permission.
Paul,
You are correct in explaining the way .local method of Application Isolation works. MSI Package has a table called IsolatedComponent table. Application Isolation Wizard populates this table by adding all the DLL/OCXs component that should go with an EXE component in this table. So now when a user installs the MSI package, MSI Engine will read this table and then install all the DLL/OCXs files associated with an EXE in the folder where the EXE file is getting installed. In addition it will automatically create the 0 byte .local file.
Now when you try to run the EXE, Windows loader will check for the .local file and if it finds the .local file it will try to load the necessary DLLs from the same folder otherwise it will look in the standard DLL lookup path.
Now for Windows XP there is a better way to Isolate. In Windows XP the information about the dependencies for an EXE file is written in Application Manifest file. This is a XML file. Then the information about each DLL/OCXs is written in a Assembly Manifest file. Assembly Manifest file contains the COM information for each DLL. The beauty of this approach is that even your COM information is localized in the manifest file and it does not live in Registry anymore. You don't have to worry about some other application overwriting the COM information. When you run the EXE, Windows loader will read the Application Manifest file for the EXE and will find out about Assembly Manifest files. Then it will read the assembly manifest files and try to find the information about the DLL that it need to load.
I took an application (Orca.msi) and Isolated it using Application Isolation Wizard using Manifest approach. After I was done, I installed the application and then I went to the folder where the application was installed using explorer. There I found two manifest files. The first manifest file is "Orca.exe.manifest". This is an application manifest file. Remember for each EXE there will be one Application manifest file. The content of this file are shown below.
-
manifestVersion="1.0">
version="1.0.0.1" processorArchitecture="x86" />
This manifest was generated by the Application Isolation Wizard
-
-
If you look at the DependentAssembly tag it clearly explains that Application depends on another Assembly named "Company.Division.Assembly2". Now I opened the second file that was named "Company.Division.Assembly2.manifest". If you open this file now you will find the following information in this file.
-
manifestVersion="1.0">
This clearly show that this assembly contains the information about msvcrt and mfc42u.dll. These DLL does not have any COM information but if they would have COM information it would have been shown here.
So in a nutshell there is a Application manifest file for every Application (EXE) and then there is Assembly Manifest file for DLL and OCXs. You can have only 1 assembly manifest file where you can put the information about all the DLL/OCXs or you can have separate Assembly manifest file for every DLL/OCXs. The naming convention that Application Isolation Wizard is using Company and then Division and then Assembly and extension has to be manifest.
The reason you don't see these files outside after you are done with Isolation is because Application Isolation Wizard streams these files into the MSI package. But when you run the installation you will see these files getting installed.
Amber Aggarwal
Senior Developer
InstallShield, A Macrovision Company
http://www.macrovision.com
http://www.installshield.com
If you're interested in more info on administrator issues, you can sign up for InstallShield's monthly AdminLetter and get Tips, popular Knowledge Base articles, Webinars, administrator-focused White Papers, etc. http://www.installshield.com/adminletter/discussion
