13

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?

Adam
  • 4,159
  • 4
  • 32
  • 53
Earlz
  • 62,085
  • 98
  • 303
  • 499
  • Really hoping someone from MS will comment on this ... – driis Oct 08 '12 at 20:46
  • Are there actually different _runtime assemblies_? (i.e. in c:\Windows\Microsoft.NET\) My (perhaps incorrect) understanding was that there were different _reference assemblies_, but that there was only one set of runtime assemblies. – James McNellis Oct 08 '12 at 20:51
  • Yes. Compare some of the assemblies in `C:\Windows\Microsoft.Net\GAC_MSIL\ ` and `C:\Program Files(x86)\Reference Assemblies\Microsoft\Framework\.NetCore\v4.5\ ` you can clearly tell they bear the same fully qualified name including keys, yet they are vastly different. Example: System.ObjectModel. One version has some types forwarded to System, and the other doesn't – Earlz Oct 08 '12 at 20:55
  • Not a good answer but it could make it easier to port code. – paparazzo Oct 08 '12 at 21:00
  • You can also see this flaw in Visual Studio. If you create a project and say, want to use WinRT's version of a system assembly(ie, with an alias) and non-WinRT's version of a system assembly, it won't let you because it thinks the assembly is already added due to the duplicate full name – Earlz Oct 08 '12 at 21:01
  • Can you give an example of when you would use both assemblies in a project? – paparazzo Oct 08 '12 at 21:04
  • @Blam I recently needed to do it when messing with Mono.Cecil because it has a bug where it can't properly get WinRT types in some cases.. so, I decided to create the WinRT type manually and pass it as a typeof().. I ended up having to replace every system reference with WinRT's because of this issue. It was just a prototype application, so this was OK... I know the use-case is slim, but I'm sure there are more uses – Earlz Oct 08 '12 at 21:06
  • 3
    The example you provided is comparing _runtime assemblies_ (those in the GAC) to _reference assemblies_ (those in the "Reference Assemblies" folder). Reference assemblies are used during build and provide metadata about types. Those assemblies may be different from the assemblies that are actually loaded at runtime. Since reference assemblies are metadata-only, they will never be loaded into an execution context at runtime. – James McNellis Oct 08 '12 at 21:12
  • Pretty sure it would not pass certification for the Metro Store. Not saying I agree but MSFT has chosen to sandbox Metro. – paparazzo Oct 08 '12 at 21:18
  • @JamesMcNellis I just went through every file resembling System.ObjectModel and checked and the full name is the same on all of them except for from the Windows Phone SDK – Earlz Oct 08 '12 at 21:30

1 Answers1

2

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'

JuanK
  • 2,056
  • 19
  • 32
  • That would be fine.... If the WinRT assemblies weren't radically different from .Net's. I mean huge amounts of types are either removed or different, yet they appear to be the same assembly. That doesn't make sense at all – Earlz Oct 30 '12 at 13:23
  • 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. – JuanK Oct 30 '12 at 13:30
  • I understand all that. Don't you think the assemblies should AT LEAST have a different version number or public key token because of this? Most people don't release version 1.0 of a product and then take that product and completely change and then update it without bumping the version number – Earlz Oct 30 '12 at 14:23
  • Another good question is why the Windows Phone 8 (WinRT) reference assemblies also share the same fully qualified name as the WinRT reference assemblies even though they are also vastly different – Earlz Oct 30 '12 at 18:40
  • Earl, but there is no other product :S I mean there is no other framework or other assembly dpong the same thing, is a proxy just for metadata :S. – JuanK Oct 30 '12 at 20:04
  • Earl, 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' – JuanK Oct 30 '12 at 20:11