I am having an issue. I am being told that the files that exist witin merge modules shoud not be included when doing file isolation, is this accurate? What are the ramifications of including merge modules files during file isolation?

Thanks in advance for any help.
0 Comments   [ + ] Show Comments


Please log in to comment

Community Chosen Answer

This is actually the subject of some debate. The key is to understand exactly what Merge Modules & Isolating does, and then decide for yourself if it's good for your environment or not. I'll summarize, but you should investigate the MSDN Library, MS knowledgebase & Wise/Installshield documentation for much greater detail.

Merge Modules: Collections of associated files/runtimes organized in such a way that when you update one of the files, it makes sense to upgrade the whole group. They help prevent you from straddling versions in a group of runtime files, for example. Also if you do conflict checking and see that you've captured an old version of one of the files, you can bring in a module to check it with the current level of the module.

Isolation: Keeps specific versions of supporting files separated so that the application uses the exact versions of supporting files it was shipped with. This makes your applicaitons more stable and less likely to conflict with other applications. If one of these files is part of a merge module, it will not be upgraded if you add a newer merge module. This isn't necessarily a problem though because the isolated application will continue to run with the version that was shipped with it. It should continue to work just fine.

BUT (and this can be big) there is a major drawback to isolating. If you isolate files that are addressed by Security Patches such as Windows HotFixes, they will most likely will not be patched and you will still run with the security vulnerability. In my environment the priority is security first, then stability. I don't isolate. Only isolate if the priority of your environment is stability first, then security.
Answered 05/24/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


Thank you very much. That has provided me with some additional clarity.
Answered 05/25/2005 by: terranceallen
Orange Belt

Please log in to comment
In my environment the priority is security first, then stability. I don't isolate. Only isolate if the priority of your environment is stability first, then security

I agree with VikingLoki here, and would go one further: in my experience, file isolation can actually <i>harm</i> application stability, especially when it comes to large complex apps with many dependencies. A lot of apps out there are poorly written with hard-coded paths and do not function well after file isolation. Add to that the considerable time it can take to troubleshoot isolation-related breakage, and I just don't see much of a benefit. OTH, merge modules work reliably all the time, with minimal effort.
Answered 04/20/2006 by: norexx
Orange Belt

Please log in to comment
Hey Viking, good read, I've been getting my mind around this stuff lately.

To your point about component isolation, wouldn't the isolated component break anyway if another incompatible version was "registered" on the system, let's say in the system32 directory, and isn't this why MSFT doesn't recommend self registration anymore?
Answered 04/21/2006 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity