4 ms·
.NET isn't what allows that to happen, though, since, AFAIK, MS has not committed to binary compatibility between .NET versions. While the framework makes it e
by cube13 15y ago
.NET isn't what allows that to happen, though, since, AFAIK, MS has not committed to binary compatibility between .NET versions. While the framework makes it easier to leverage these features(you can still use it with non-managed C++ but it's quite annoying to get working), the Windows kernel is what allows the multiple versions to exist.
In the case of .NET, it's the side-by-side deployment of the .NET runtimes that allow multiple versions to be present on the system at the same time.
- daeken 15y ago> the Windows kernel is what allows the multiple versions to exist. I don't think you know what the Windows kernel does. Multiple library versions have nothing to do with the kernel because 1) the kernel doesn't know anything about libraries, 2) the kernel doesn't do userspace binary loading (even for completely unmanaged code), and 3) the kernel does nothing at all with .NET. Side-by-side deployment of binaries is actually completely separate from the functionality in .NET that allows multiple versions, which is the GAC (Global Assembly Cache); SxS binaries (which are used by unmanaged code) are completely separate, although they both reference their respective binaries via manifest files.
- brudgers 15y agoInteresting point, but the net result is the same.