(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
In a recent post on Wesner Moise's blog, you'll find the following rather remarkable snippet:
"In a break from the present scheme, Longhorn will no longer support multiple CLRs. Every managed application will be forced to use the latest version of the CLR on the system."
This is a rather substantial change from how things work today. However, it's not really all that surprising - after all, it's
how Windows has worked for years. You can't have 5 different versions of kernel32.dll installed.
So does this mean that Microsoft have decided that the whole strongly-versioned assembly reference thing was a bad
idea, and that we may as well give up and resign ourselves to DLL hell? No - this change in approach to versioning is intended
just for the CLR itself, and it's more a statement that the platform versioning is different because it has to be. Current versions of
the .NET Framework sit on top of the underlying Windows platform, but
once the distinction between CLR and platform blurs with Longhorn, it will no longer make sense to talk about having two
different .NET Framework versions hosted on top of the same Windows version. (No more than it would make sense to try and
run multiple copies of kernel32.dll.)
It requires a massive commitment to backwards compatibility for this to be workable. And Microsoft have consistently demonstrated how seriously they take that commitment over the last couple of decades.
For the rest of us, the existing versioning semantics for non-platform components will continue to apply - we will not have to try and deliver the same level of backwards compatibility that Windows does.
Also, note that the scope of this "one version only" idea looks likely to be fairly narrow. Individual libraries shipped as part of the .NET Framework libraries are likely to carry on supporting independent versioning. It seems that only the core parts of the platform are going to be one version per machine.