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
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)
Please log in to answer
Posted by:
VikingLoki
19 years ago
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.
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
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.
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
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
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|]
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
Posted by:
Thaiboxer
19 years ago
Posted by:
shogun_ro
18 years ago
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.
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.
so that the conversation will remain readable.