.NET版本兼容的严格性和强制性引出了一个很有趣的问题：如果一个应用程序以.NET的2.0版本生成，当.NET的3.0版本可用时，该应用程序将不会利用3.0版本的改进。原因是应用程序清单中包含了所以依赖程序集的版本号，包括CLR和应用程序框架。.NET程序集是强命名的，因此程序集解析器会坚持正确版本的匹配。为了克服自身程序集的版本兼容问题，.NET必须提供了一套不同的基本规则，所涉及的问题错综复杂 。通过类库或EXE中的组件使用的CLR的正确版本可能是多样的，它依赖于与之编译的版本，可用的.NET版本，以及应用程序版本策略。
.NET构架试图在创建新版本和支持现有应用程序之间取得一个平衡。最终，它决定由应用程序提供商来决定是否支持一个具体的CLR版本。这标志着一个观念的改变：微软不再绝对保证向前和向后兼容。相应地，微软承诺尽一切努力将向后兼容，并会指出哪里是不兼容的。这就意味着一个新的.NET版本不会完全向后兼容。 这项保证的一个例外是安全性——微软为了处理安全漏洞会故意在.NET新版本中作出变动。
CLR的并行执行
即然CLR和各个.NET应用程序框架由许多程序集组成，那么它们可以被视为一个单独的版本单元。这些单位的多个版本可以在任意计算机上共存，这被称为CLR“side-by-side execution（并行执行）”。并行执行是可行的，是因为.NET部署在GAC中，而且GAC支持同一程序集的多个版本的并行执行。所以不同的.NET应用程序可以同时使用.NET的不同版本。也可以安装.NET的新版本或移除现有版本。并行的方式降低了当安装一个应用程序而影响另一个的可能性，因为较早的应用程序仍然可以使用较早的.NET版本。即使如此，.NET并行执行是允许选择何时升级到下个.NET版本，而不是让它脱离最新的CLR 版本。
版本的统一化
所有的.NET应用程序都寄宿于一个读取CLR DLLs的非托管进程中。该非托管进程可以使用每个CLR程序集的正确版本。此外，CLR的版本号支配哪个.NET应用程序框架版本可以使用，因为它们被视为一个单独的版本单元。事实上.NET总是在一个統一的框架程序集堆栈中运行，称为“version unification（版本統一化）”。統一化的要求是因为CLR和.NET应用程序框架不是为混合和匹配而设计的，就是说，不可以一些程序集来自1.1版本而一些版本来自2.0版本。
通常情况下，一个.NET应用程序包括一个单独的EXE应用程序程序集用于启动进程，并且将潜在的多个其他程序集读取到进程中。统一化就意味着在一个进程中包括一个托管应用程序，EXE应用程序程序集和它读取的程序集都使用同一.NET版本。该进程中是由用于启动进程的EXE来选择CLR和应用程序框架的版本； 而其他读取的程序集无权过问。例如，在.NET（.NET 1.0）第一次发布中的所有程序集的版本号都是1.0.3300.0。在.NET（.NET 1.1）第二次发布中的所有程序集的版本号都是1.1.5000.0。假如一台计算机上同时安装了这两个版本。当一个EXE程序集使用.NET的1.1.5000.0版本时，通过它读取的所有程序集都会使用1.1.5000.0版本，即使它们是使用1.0.3300.0版本编译的。这样是没有问题的，因为.NET1.1是向后兼容1.0版本的。但是，反过来如果EXE程序集选择了1.0.3300.0版本，通过它读取的所有程序集都会使用1.0.3300.0版本，即使它们需要1.1.5000.0版本的新特性。这样就可能导致应用程序发生故障。
注意，避免使用自定义版本绑定策略来覆写同一化。他会导致不可确定的结果。
指定一个CLR版本
在一台给定的计算机上，可以有任意CLR版本组合。应用程序可以隐式依赖与默认的版本决定策略，或者可以显式地提供配置信息指示支持的CLR版本。
默认版本绑定
如果一个应用程序没有指示.NET需要哪个版本的CLR，那么应用程序就是实际上告知.NET任何兼容的CLR版本都是允许使用的。在这种情况下，.NET会检测与应用程序编译的CLR版本，并使用本机上最新的CLR兼容版本。为此，.NET必须知道哪个CLR版本是与其他版本向后兼容的。现在，微软认为所有新的.NET版本应是向后兼容的。注意CLR向后兼容与向前兼容不一样。向后兼容处理的是一个以较早版本编译的程序集是否可以在较新版本上执行的问题。向前兼容处理的是一个以较新版本编译的程序集是否可以在较老版本上执行的问题。向后兼容是主要变动产品对类型定义和类型的行为。向前兼容是通过元数据版本来控制。.NET 1.0和.NET 1.1拥有同样的元数据版本，所以他俩之间同时向后和向前兼容。.NET 2.0拥有一个新的元数据版本，所以它只考虑向后兼容——.NET 2.0程序集需要.NET 2.0运行时。
下边这个表描述了CLR版本兼容矩阵。左侧列列出了与程序集编译的CLR版本，其余列列出了这些程序集是否可以在其他CLR版本上运行：
| Assembly\CLR version | 1.0 | 1.1 | 2.0 |
| 1.0 | + | + | + |
| 1.1 | + | + | + |
| 2.0 | - | - | + |
在注册表中维护着一个相似的兼容表。当.NET决定将哪一个.NET版本提供给应用程序时会使用该表（默认使用最高可用的兼容版本）。
指定支持的CLR版本
使用默认版本可能导致应用程序运行于未经测试的CLR版本，而导致不可确定的行为。如果不想应用程序依赖于默认的版本绑定策略，并且拥有确定的行为，那么可以提供显式的版本配置。在这种情况下，应用程序必须在其配置文件中使用带有supportedRuntime属性的startup标签指示哪一个CLR版本是它支持的：
通常来讲，不应将没有通过测试和验证环节的CLR版本添加到该列表中，以确保版本的兼容性。CLR 版本列出的顺序表明使用的优先权。.NET会尝试提供第一个CLR版本给应用程序。如果该版本在本级上是不可用的，.NET会继续尝试列表中的下个版本。如果指定的版本没有一个可用，.NET会拒绝读取应用程序，并显示一个消息框要求用户安装在配置文件中指定的最近的一个支持版本。注意，startup会指示覆写任何.NET可以提供的默认行为，这就意味着即使另一个兼容版本在本机上是可用的，如果它没有在配置文件中列出，.NET会拒绝在该版本上允许应用程序。