Handling Dependent Reusable Components

More often than not, Application packages include dlls components that are reusable from other parties. The most common are the Microsoft Visual C++ runtime components (although there are many other sources as well).

In a native installation, these components may be installed either into system locations or in the same package folder with the application. In the application repackaging industry, there are two different schools of thought on how to handle these components.

These two approaches are as follows:

• One is to identify dependencies, separating them for independent delivery, and removing them from the repackaged app.
• The second is to keep them within the repackaged app.

Although some organizations believe their approach is the right one to use, the truth is that: there's not a one-size-fits-all method that works for all organizations, and using only one approach may not be suitable for all situations within any organization.

Traditionally, we worried about version conflicts when these components were written into shared areas, a concept referred to as “dll hell”, where installing one new application might break any of the others on a system and you wouldn’t know unless you test all of them.

Today, different versions for most of these components are installed into different file locations, even in a system installation, so it is less of an issue. The problem now tends to be with older application installers that add known flawed shared components that lack fixes for known security vulnerabilities, and we want to ensure these are always patched.

Organizations using Configuration Manager to deploy apps repackaged as MSIs usually prefer the separation approach. While organizations repackaging for an isolation environment, such as App-V or MSIX tend to take the other approach; which takes much less work and it is less unlikely for vulnerabilities to be exploited, especially in an isolated environment.

We're not here to guide you through what the best approach is for you. But, to make you aware of these choices we recommend that you follow the approach(es) used by your organization. We can also suggest that as you gain more experience and changes occur in the technologies we use, the so-called “correct” approach today may not be so “correct” in the future.