/build/static/layout/Breadcrumb_cap_w.png

Isolation of Dll's ? Is it worth

Hello Group,

Please give me your comments on the following

I need to know what are the disadvantages of Isolation.

Is it really worth isolating every product that you package. how much of a trade off it is between compromising security and value it brings to the organization

According to MSIMAKER they do isolatate all the products they package excluding Microsoft OS and Office Dll's.

How about MDAC and .Net dll's ?

Correct me if I am wrong...most of the time the the common dll's belong to either OS, Office, MDAc or .Net (mainly microsoft components) which are subject to patches by microsoft.

Thanks

0 Comments   [ + ] Show comments

Answers (8)

Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
Isolation is a bit of a double-edged sword.

PROS:
Applications are more stable because they run with the exact version of DLL/OCX files tested and distributed by the vendor.
An isolated package will not cause any conflicts with other applications.
All and all, from an application point of view isolation is a very good thing.

CONS:
If you isolate files contained in a security patch, they will NOT be patched unless you create and distribute your own patch for the application.
From a security patching point of view, isolation is a very very bad thing.

I was part of the "isolate everything" camp until my epiphany with the security patch thing. I concluded that the best approach is that if the file might be part of a Windows HotFix, leave it in System32 where the patch will find it. The biggest criteria for that is to see if Microsoft is the vendor listed in the file properties, and best guess. To reduce conflicts, I use conflict manager and test with the highest version of the file that I have and if sucessful I encorporate that file in the package.

For example, I package an app called Thing 3.4 from Widgetco that has 2 DLLs (or any other kind of library file), Widget.DLL and MSSTUFF.DLL. Widget.dll looks like a vendor specific file that won't be in any other non-Widgetco app. Widget.dll gets isolated. MSSTUFF.DLL has Microsoft listed as vendor in the file properties. MSSTUFF.DLL stays in System32. if MSSTUFF.DLL is v6.5 and the highest version I had previously was 8 apps at v6.2, then I bitch and moan and test those 8 apps with MSSTUFF.DLL v6.5. If all 8 apps run fine with that DLL upgraded from v6.2 to v6.5, then v6.5 becomes my new standard. The 8 older apps stay at 6.2, but any new application that gets packaged will be tested with replaced with v6.5. I have yet to find an application where a newer version of a DLL/OCX breaks something, I'll burn that bridge when I get to it.

If anyone thinks there is a better way, please speak up. I'm quite open to other strategies.
Posted by: kkaminsk 19 years ago
9th Degree Black Belt
0
I think the Pro's were covered but I will add to the potential CONs.

When I was on a large scale Windows Installer project we had an on site developer from Wise show us some of the best practices. What he wanted us to do is isolate everything. At first this seemed like a great idea except you have to keep in mind that not every application will successfully isolate.

I think isolating everything is a bad idea but to know if using isolation on a broad scale actually saves you money is a whole different issue. During the course of the project we could only find about 3 applications that actually needed to be isolated. So was the experiment in application isolation of value? I can say no based on the one experience I had because it would have been cheaper to ignore isolation until it was required.
Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
True, isolating does add to development time and that = $$$. Any app that makes a hard-coded call to System32 will not isolate and you can end up wasting a lot of time trying to get it to work to no avail. With that I should modify my isolation recomendation. Vendor/App specific support files, isolate. MS/Windows support files, do not isolate. And do not go to excessive lengths to isolate, if it doesn't go easily don't try to take it kicking & screaming.
Posted by: Thaiboxer 19 years ago
Orange Belt
0
My $.02 -

I've had good luck isolating on a number of apps and have worked at companies where it was standard practice, but the security patch epiphany got us as well. Every time the Microsoft DLL's change you have to repackage everything... so that practice got dumped rather quickly.

Hey VikingLoki, is Widgetco hiring? Sounds like a fun place to work [8|]
Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
Yeah, but you get paid in doo-dads. The free whatchahoozits are a nice perk though. [:D]
Posted by: Thaiboxer 19 years ago
Orange Belt
0
Free whatchahoozits? Count me in! That beats my benefits right now!
Posted by: RP 19 years ago
Yellow Belt
0
Thank you all who replied
Posted by: shogun_ro 17 years ago
Orange Belt
0
I know i am a little bit off-topic but i have a really big problem:

Right now i am organizing a packaging training with some new guys employed by my company and i need to show them how to solve conflicts. Unfortunately i am somewhere in germany and i have no access to my company's network from Romania and i need to find 2 applications that have some conflicts between them. I tried ten packages and no conflicts. :)
And when i was packaging a few months ago i had conflicts for every package. :D

Can you give 2-3 examples of applications that have conflicts between them?

You will be of a real help.

Thanks.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ