Application Isolation Wizard - Installshield
Or this could be titled "How the heck do you make Application Isolation using manifests work"
I'm a bit of an application isolation newbie so maybe this is a really dumb post, so please bear with me...
I think I understand using the .local method of application isolation, where you put all the relevant .dlls/ocx's etc into the same directory as the executeable and create a .local file, am I correct in that much?
But what I've read seems to suggest using a .manifest file is better for XP. These are .xml files that contain not just information about where the .dll files are and redirecting the application to use them, but it appears they can contain .com registration information that would normally be in the registry. MSDN has some very dry documentation about the syntax of such files (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/side_by_side_assemblies_reference.asp)
.
I'm trying to use the application isolation wizard that comes with Installshield, but when I run it against an MSI I get some rather confusing screens. Taking pcanywhere as an example, I get a screen like this (when clicking on the "modify" button)
awhost32.exe
Company.Division.Assembly4
And in the right hand pane are all the files, with a few selected. msvcp60.dll and msvcrt.dll
What I want to know is - what does this mean? Does this mean it will move these .dlls to a directory in the MSI and create some link to it in the .manifest file? Can I specify where it moves them to? How do you determine which DLL's should be isolated in relation to which .EXE's (say for example if the package has 5 executables) - should I use a tool to analyse dll dependancies, or is there an easier way?
Also, how does it handle the registry information related to COM registration etc?
Rgds
Paul
I'm a bit of an application isolation newbie so maybe this is a really dumb post, so please bear with me...
I think I understand using the .local method of application isolation, where you put all the relevant .dlls/ocx's etc into the same directory as the executeable and create a .local file, am I correct in that much?
But what I've read seems to suggest using a .manifest file is better for XP. These are .xml files that contain not just information about where the .dll files are and redirecting the application to use them, but it appears they can contain .com registration information that would normally be in the registry. MSDN has some very dry documentation about the syntax of such files (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/side_by_side_assemblies_reference.asp)
.
I'm trying to use the application isolation wizard that comes with Installshield, but when I run it against an MSI I get some rather confusing screens. Taking pcanywhere as an example, I get a screen like this (when clicking on the "modify" button)
awhost32.exe
Company.Division.Assembly4
And in the right hand pane are all the files, with a few selected. msvcp60.dll and msvcrt.dll
What I want to know is - what does this mean? Does this mean it will move these .dlls to a directory in the MSI and create some link to it in the .manifest file? Can I specify where it moves them to? How do you determine which DLL's should be isolated in relation to which .EXE's (say for example if the package has 5 executables) - should I use a tool to analyse dll dependancies, or is there an easier way?
Also, how does it handle the registry information related to COM registration etc?
Rgds
Paul
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
MSIMaker
20 years ago
Don't be sorry for being a newbie at all.....if you don't ask for help you will stay helpless and a newbie...so your officially NOT a newbie in my opinion :)
You have this right....and it works very well except for 16bit apps. This is 32bit only.
These files and associated registry entries should be removed because they are OS and Office specific files which will cause problems if you ever remove PCAnywhere in the future. I think IS has noted this and highlighted it to you.
I dont have first hand knowledge of InstallShields abilities but if you have doubts about the files you are including in your packages then make sure you use the conflict manager to confirm that you arent making troubles for yourself.
It takes a while of doing this to instantly recognise dll's that might be a problem but after a while you get to know them on sight.....until then try to learn and rely on whatever tools you can get ahold of.
I suggest you look at Bob's PackageCleaner demo and see if that might be the type of tool you would find useful while you are in this phase of learning. After using it for a while it will become second nature to spot the baddies.
I think I understand using the .local method of application isolation, where you put all the relevant .dlls/ocx's etc into the same directory as the executeable and create a .local file, am I correct in that much?
You have this right....and it works very well except for 16bit apps. This is 32bit only.
And in the right hand pane are all the files, with a few selected. msvcp60.dll and msvcrt.dll
These files and associated registry entries should be removed because they are OS and Office specific files which will cause problems if you ever remove PCAnywhere in the future. I think IS has noted this and highlighted it to you.
I dont have first hand knowledge of InstallShields abilities but if you have doubts about the files you are including in your packages then make sure you use the conflict manager to confirm that you arent making troubles for yourself.
It takes a while of doing this to instantly recognise dll's that might be a problem but after a while you get to know them on sight.....until then try to learn and rely on whatever tools you can get ahold of.
I suggest you look at Bob's PackageCleaner demo and see if that might be the type of tool you would find useful while you are in this phase of learning. After using it for a while it will become second nature to spot the baddies.
Posted by:
plangton
20 years ago
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.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity type="win32" name="Company.Division.AppAssembly2"
version="1.0.0.1" processorArchitecture="x86" />
<description>This manifest was generated by the Application Isolation Wizard</description>
- <dependency>
- <dependentAssembly>
<assemblyIdentity type="win32" name="Company.Division.Assembly2" version="1.0.0.1" processorArchitecture="x86" />
</dependentAssembly>
</dependency>
</assembly>
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.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity type="win32" name="Company.Division.Assembly2" version="1.0.0.1" processorArchitecture="x86" />
<file name="msvcrt.dll" />
<file name="mfc42u.dll" />
</assembly>
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
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.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity type="win32" name="Company.Division.AppAssembly2"
version="1.0.0.1" processorArchitecture="x86" />
<description>This manifest was generated by the Application Isolation Wizard</description>
- <dependency>
- <dependentAssembly>
<assemblyIdentity type="win32" name="Company.Division.Assembly2" version="1.0.0.1" processorArchitecture="x86" />
</dependentAssembly>
</dependency>
</assembly>
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.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity type="win32" name="Company.Division.Assembly2" version="1.0.0.1" processorArchitecture="x86" />
<file name="msvcrt.dll" />
<file name="mfc42u.dll" />
</assembly>
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.