Software Deployment

If you want to totally isolate ActiveX type DLLs/OCXs etc, then you need to use .manifest files which only work with WindowsXP and above.

The .manifest file is kind of like the .local file, apart from the fact that the regsitration information for the component is stored in this .manifest file in a XML format.

Hey Misk,
All registration info is in the .local file, so it uses this file instead of looking at the registry.

ORIGINAL: misk

ok folks, here is my scenario,
we have to isolate all dlls and ocx that install to the sys32 dir. so using wise's isolation wizard we create a .local file beside the exe.I understand that the exe now looks locally for the dll, but what about the registry entries?
the dll is already on the build, so my app is now overwriting system32\mfc.dll with [!mfc.dll] in the registry. is it safe to remove all these conflicts?
does this method of isolation manage registry entries?


system32\mfc

If the Dlls/Ocx files that you want to isolate do not require registration, you should be able to isolate them by moving them to the same folder as the executables that depend on them.

If the Dlls/Ocx files that you want to isolate are active-X components and need to be registered, you cannot isolate the application by simply moving the library to the application folder(s). A "shared" (non-isolated) copy of the library must exist and must be registered for use by other applications. The ".local" file only causes the "InProcServer32" or "LocalServer32" paths to be ignored, or forces the "LoadLibrary" method to use the local folder first.

Beware, incorrect isolation can do more harm than good. And you'd be surprised how many companies are doing it very wrong because they don't understand the process correctly!

".local" files do not contain any registration information, and the registry is still required (the shared copy will take care of this). Read up on the "IsolatedComponent" table for more information.

cheers WiseUser. So keeping my current predicament in mind, i should only isolate the components that are not registered, i should leave the registered components to install normally.

out of interest what are the effects if i isolate a dll that is not registered but already part of the build? any issues there?

would you agree .local is a poor method for isolation? does the .manifest method tackle these registry problems any better?

I'm not telling not to isolate registered files... I'm only urging you not to remove the "shared" ("Sytem32" or other) version. Using the "IsolatedComponent" table is designed to do this automatically, but Wise have made things more difficult with their "efficient" feature tree structure. This can be reversed by moving all components to the "complete" top-level feature if you wish.

The goal of isolation is to prevent or minimise the chances that an application will be affected by changes taking place outside it's own application folder. Not everyone agrees with isolation as a matter of course. An isolated application may not benefit from some important bug fixes for example.

Some libraries can't be isolated. Many of these are listed under the following registry key:

"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs\"

In most cases unregistered files can easily be isolated by copying/moving them to the application folder and creating a ".local" file for every executable that you wish to isolate.

If an active-X is installed and registered as part of your build, copying it to the application folder and creating your ".local" files may be sufficient.

Experiment using ProcXPNT (by Sysinternals) to verify where your application is loading libraries from (you may need to add an extra column to the Dll view).

i am greatful for all the info, thank you all kindly.

Could anyone comment on success / problems with using .manifests to get around this problem???

They seem a great solution if you are just packging for XP, so I wondered if there was a catch?

Thanks

Gordo

There is a huge catch! See here for details...

http://myitforum.com/articles/6/view.asp?id=5206

Just get it fixed Misk...we aren't paying you these MASSIVE contract rates to browse around on the Interweb all day!

The following section in blue is an exceprt from an email sent to me by one of the developers from Installshield explaining how the .manifest works, its pretty comprehensive in my opinion:




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.

Thanks for that plangton - it does explain it quite well.

That was how I understood manifests to work, but WiseUser's link above suggests that manifest will only work for applications that have been written to make use of .NET architecture, which is still a relatively rare thing - in the world of re-packaging anyway.

Does this mean that using manifests is a great idea in theory, but in the real world when re-packaging legacy applications they can't be used???[:(]

Not in my experience, it has worked for non .NET apps, and I confirmed that this morning with a bit of Filemon goodness. My understanding is that it isn't .NET that enables to .MANIFEST, but XP itself. But you are right, reading that document does seem to indicate that it does ...

Do a test yourself, run FileMon, and then run a non .NET app (for this example, I used notepad). The very first thing Windows looks for is a Notepad.exe.manifest file. Then it looks for a notepad.exe.local

Friends,

Reg App Isolation, I just isolated an application for Windows 2003 Server OS build. What I have noticed is that even though it moved all the DLLs in question to app folder (C:\Program Files\<app name>\), it keeps the full path for every isolated DLL in the registry. So in this case I have two paths for same DLL. 'C:\Windows\System32\Comcat.dll' and 'C:\Program Files\<app name>\comcat.dll'.
My question is, if we have two paths for the same DLL, would'nt it be conflicting with other apps? How can we just use the local DLLs without having path in the registry? - Thanks