C5/.NET Native Compilation about c5

[MattWhilden]

I work on the .NET Native runtime and compiler team. We'd be interested in investigating this a bit. Any chance someone hitting this can shoot us a mail at [email protected]?

[ondfisk]

Just tried building a UWP app targetting 1809 with latest C5 beta. I was able to create an app package.
@danielgary can you try again?

[ondfisk]

This should be solved with the 3.0.0 release as of today.

[MattWhilden]

I'm in contact with the maintainer of this package. We'll get sync'd up and see what progress can be made.

[danielgary]

Any updates on this Matt?

[MattWhilden]

I feel terrible, I seem to have completely lost the email thread this was attached to so I'm not sure what happened. I'd like to assume that this was resolved but that may just be optimism. I'm at //BUILD this week and don't have a ton of time to chase this down until Monday... Sorry... If it's fixed, it'll be available in this beta build (https://www.visualstudio.com/downloads/visual-studio-next-downloads-vs) of VS or in the update to Windows tools in mid Feb.

[danielgary]

Thanks for letting me know, and no worries. I was reading up on the .NET native improvements. I'll give it a try this week and post results. Thanks!

[MattWhilden]

Here's the announcement for new tools: https://blogs.msdn.microsoft.com/visualstudio/2016/04/11/whats-new-in-vs-2015-update-2-for-universal-windows-developers. Do let us know if there's anything else odd... either tag me or mail [email protected] :-)

[MattWhilden]

I'm not sure if it's the same issue but using the Update 2 tools does not allow this package to successfully compile. It's an issue on our side but will require some decently large feature work to accommodate. There's some details below that may help someone if they have the desire to fight with it some more. I've logged a bug in our internal database to track getting this corrected.

Because UWP applications are ahead of time compiled with .NET Native we need to be able to identify all of the generic types you'll want to use at runtime. The analysis here is a bit tricky and we're somewhat greedy because not having code at runtime is highly undesirable. However, it does mean that there are some code patterns that lead to infinite expansions/recursions in the generics we suspect you'll want. Instead of attempting to generate an infinite number of generic types we bail out when we hit something that is some number of levels deep (18 I think??).

It's possible that with a bit of hacking and munging of C5 that the issue could be avoided but I haven't had time to run any experiments. For those interested, the problem seems to be tied to code generation around C5.Showing.ShowCollectionValue.

[MattWhilden]

As a helpful bit of text for search indexers here's the error output:
error : Error: NUTC3054:The generic parameters are too complex. This may be an indication of infinite generic expansion which is not currently supported while loading type 'C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair2<C5.KeyValuePair`2<System.__Canon, System.__Canon>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>, System.Int32>'. while computing compilation roots.

We haven't yet completed the work to correct this issues but we're still working on it. It's very useful for our prioritization to know how many folks are impacted by this kind of issue so feel free to let us know (either this thread or mailing us at [email protected]).