Spec on asset composition / coherency

[richlander]

I've been watching this project move forward over several months. Great work.

If I think broadly about what I've observed, it has been a lot of focus on type system coherency, towards the end of seamless interop between WinRT and CLR type systems. #306 is squarely in this camp.

We're more or less done type type system coherency now, and are turning to asset coherency. This is a very different and much broader domain with its own set of rules, and a lot more UX to consider. #304 is squarely in this camp.

I think we need a scenario-oriented spec on how we want this to work. Some of us have raised a concern that the CsWinRT package contains both tools and the base of the type system. That seems like an unfortunate choices to me. A scenario-oriented spec will hep us make decisions on this and other issues we discover, based of finding flows that are straightforward or challenging.

It appears that we're close to the finish line right now (and running out of schedule runway) so I think there will be a natural tendency to deal with the feedback we get, but not fully look at the bigger picture. Even if we don't resolve everything in the near-term, I think it is super important to see this bigger picture to help us prioritize what to fix now.

Thoughts?

[raffaeler]

Some of us have raised a concern that the CsWinRT package contains both tools and the base of the type system. That seems like an unfortunate choices to me.

I personally agree. But if the tools and the rest are split, I would like them to be both usable at runtime as libraries.
Most of the time the tools will be used at compile time, but it could be useful to use the tooling at runtime as well.

[richlander]

Hey @raffaeler! I hope you are well.

Can you elaborate with scenarios? That will help the team a lot.

[raffaeler]

Hi @richlander everything ok thanks. I hope you are all ok as well.
I just miss travelling in conferences, but next week I will give an online session :)

If I am not missing anything, this project is about two things:

• a source code generator starting from ECMA-335 metadata used by WinRT
• a library to support the generated code, including type system support

The source code generator is meant to create the .NET side of the WinRT ABI standard aka 'projection'. Other projects like cppwinrt (and hopefully others covering other languages) cover other projections.

In the dynamic languages scenario, there is already half of the work done for python and some day I would expect javascript to be part of this ecosystem of projections.

Said that, I would expect to be able to generate the projection on the fly and compile in memory in order to get the interop code needed to "talk" with dynamic languages.

Example.
Sometimes ago I wrote a C++ plugin for node.js that is able to:

1. host the core clr inside the nodejs process
2. generate at runtime the interop code (using expression trees and pinvokes) to use any C# library from javascript.
3. support any call (including async stuff, because I maintain a native queue that uses nodejs threading model)
   Last year, during the MVP Summit, I demoed the running samples to Steve Sanderson. I also previously demoed this stuff in a Siberian conference.
   This plugin must be able to generate the code on the fly because of the dynamic nature of nodejs.

In this scenario, I could replace the pinvokes with the code generated by cswinrt but the code generation must happen at runtime.

Does this make sense? Does this example help?

[Scottj1s]

@richlander, thanks for raising the issue. I'll attempt to gather all the concerns together into a spec proposal for review.
@raffaeler - thanks so much for the scenario thinking. It always helps to get concrete.

[weltkante]

The issue is a bit vague so I don't know if it fits in, but an important scenario we have is the extensible application model (think for example VS extensions). When RCWs for COM interop are no longer provided by the runtime you'll want to make sure that you are very aware of how the generated types compose in an extensibility scenario, otherwise its easy to break applications supporting plugins/extensions.

Something that has come up repeatedly in other discussions is where the RCWs are defined. #304 suggests supporting inlined definitions and #314 suggests generating the closure of interop definitions at build time.

I already commented on those issues, just wanted to drop that here again since you are looking for concrete scenarios to support. In particular for extensibility you'll want to do some consideration around binary compatibility across tool versions because in the extensibility scenario you may be loading assets generated by different tool versions into the same process.

It probably needs to be specced what compatibility you support and it probably needs to emit some sort of versioning into metadata to allow rejecting assets generated by incompatible tool version. (Rejection may or may not need to happen automatically, but definitely I expect some users wanting to build logic around it, so the information needs to be present.)

[AdamBraden]

For 1.0 we are releasing cswinrt as a single nuget. Will revisit based on feedback.
We are looking at a solution for 'embedded' scenarios that include winrt.runtime sources. #304

[raffaeler]

@richlander I have a lot of thoughts on the future of this project.
For example, I am wondering whether we can see it running x-plat.