Why do WinRT framework assemblies have the same fully qualified name as their (different) non-WinRT counterparts?

Question

This is really just more of a curiosity type question. I deal with looking up types across assemblies and raw IL. Windows 8 really puts a kink in something I'm implementing though. I've found that WinRT and non-WinRT framework assemblies share the same fully qualified name.

So, it's impossible to objectively tell if an assembly is relying on WinRT or non-WinRT versions of the framework assemblies(and yes, it's possible to use both). These assemblies are vastly different however in layout and in types implemented.

Why did they not change the public key token or version number in building the WinRT assemblies?

Answer 1

WinRT has a set of projections, one of them is designed to project winrt apis as '.net framework' friendly way, another projections are used to Cpp and for html/js stack.

In fact if somebody wants to crete new projections to support other languages and frameworks they could do it.

Making things look like .net framework have an important set of purposes:

Firstable developers who already known .net development doesn't need to start from scracth, winrt looks pretty much as a normal .net framework program.

Then exists a lot of .net framework code that is platform independ, so this code could be recompiled or reused in any environment supporting a just a subset of framework core routines, this is a key topic because this provide a simplified way to give .net functionalities to .net developers.

And last but not least, current .net developers have created a lot of code, and one commitment of microsoft when create '.net' projection was provide some compatibility with already created .net routines and this is the explanation because some assemblies mantain some stubs and signatures looking as .net framework counterpart.

They are reference assemblies, that's meaning something like 'proxy assemblies'. A proxy must look as real object is, in some way but not a complete image of the real object. You must to be clear that Winrts .net projection is not about full .net reference assemblies, there is no .net framework in WinRT just a small subset of features. That's the reason because you don´t have all the types and off course you don't have all methods or properties.

there is no other product,I mean there is no other framework or other assembly doing the same thing,is a proxy just for metadata.Is not other .Net Fx version , absolutely not. Is an assembly created to stablish a bridge between a Runtime and other crossing some platfform boundaries.So I think is perfectly aceptable setup FQN with same name because in future release maybe could exists another reference assemblies to another .net fx version.I believe use same name and version is a shortcut to know wich .net fx assembly are you referencing and btw preserve an assembly name 'compat layer'