Ensure implicit casting of lists of objects which are WinRT components works

[benstevens48]

This is just to put this on your radar. I haven't tested it with the new toolchain so everything may work fine, in which case you can ignore it. I originally posted this here but they suggested this was a better place.

Just in case no-one has considered it, I thought I'd mention a source of crashes with the existing implementation of casting of WinRT component instances in a C# UWP app (using the old toolchain, not the new C#/WinRT-based one).

Implicitly casting a list of class instances to a list of interfaces that they implement frequently results in an app crash when the list is used later on. For example, if I do this:

var myList = new List<StorageFile>();
//add some storage files to list
var dataPackage = new DataPackage();
await dataPackage.SetStorageItemsAsync(myList);

Then the app crashes (well it did last time I checked, but I haven't tested recently). Note that the definition of dataPackage.SetStorageItemsAsync is

public void SetStorageItems(IEnumerable<IStorageItem> value);

so the list is implicitly cast from IEnumerable<StorageFile> to IEnumerable<IStorageItem>.

This is not the only case where I have experienced problems before. In one case the crash actually went away by looping through the list using an iterator with empty body, like

foreach(item in list){
//Do nothing!!
}

This was terribly confusing as I only added the loop to try to debug the issue (I had a Debug.WriteLine in it to start with) and it turned out that my debugging code fixed the problem!!

I hope that C#/WinRT can handle this implicit casting of lists correctly.

[davidwrighton]

I'm was an architect on the .NET Native toolchain when we built the interop layer that @benstevens48 is describing as having these crash bugs. I'm not in a position to describe the behavior that CsWinRT will provide for this scenario, but this was one of the trickier cases to handle with WinRT interop in a completely precompiled fashion. In particular the detail is that the C# interface IEnumerable is a variant interface, which means a class that implements IEnumerable may be used as an IEnumerable, or even as IEnumerable. This flexible interface relationship is not present in the underlying WinRT type system and the interop system needs to simulate the possible behaviors. We believed that we had caught most of the ways this could go wrong with the UWP compiler, but issues like this have been a continuing source of difficulties for customers.

[Scottj1s]

@davidwrighton - thanks, this could well be a variance-related limitation.

[AdamBraden]

We don't support automatic variance beyond what dot net would automatically do. If there is a bug/crash you see, please open a new issue.