Application modernisation
Dependency
Application dependency
An application dependency is a shared component, most commonly a runtime library or framework, that an application relies on to run correctly but does not include within its own package.
Why Dependency matters in a Microsoft estate
Dependency matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
How Dependency shows up in practice
In an MSIX context, dependencies are declared explicitly in the package manifest rather than assumed to already be present on the target machine the way a traditional installer often does. The most frequently encountered dependencies in a Windows packaging estate are framework packages such as the Visual C++ Runtime (VCLibs), the .NET runtime, and the Windows App SDK, each published as its own MSIX framework package that multiple applications can share rather than each application bundling its own private copy. This keeps individual application packages smaller and ensures every dependent application benefits when the shared framework receives a security update. Getting dependency declarations right is one of the more common sources of packaging failures that only surface at install or launch time rather than at build time.
A manifest that declares a dependency on a framework version the target device does not have installed will fail to install, a dependency declared too loosely can pull in an untested framework version on a device with a newer one already present, and a dependency omitted entirely produces an application that installs successfully but crashes on launch because a required runtime component is missing. This is why dependency version ranges need deliberate testing rather than being copied unexamined from a template. This is a genuinely different failure mode from the dependency problems traditional installers created, commonly summarised as DLL hell, where multiple applications competing for the same shared, unversioned system location could silently overwrite one another's required library version.
MSIX's framework package model keeps multiple versions of a shared dependency installed side by side and lets each application's manifest pin the version range it was actually tested against. This removes the silent-overwrite failure mode, but replaces it with the discipline of keeping manifest dependency declarations accurate and current as applications and the shared frameworks they rely on are both updated over time. At estate scale, dependency management also becomes a governance question: tracking which framework versions are deployed across a device fleet, which applications depend on frameworks approaching end of support, and coordinating framework updates so that a security-driven bump to a shared runtime does not break an application whose manifest pinned an older, narrower dependency range than it should have.