You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
varmyList=newList<StorageFile>();//add some storage files to listvardataPackage=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
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.
The text was updated successfully, but these errors were encountered:
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.
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:
Then the app crashes (well it did last time I checked, but I haven't tested recently). Note that the definition of
dataPackage.SetStorageItemsAsync
isso the list is implicitly cast from
IEnumerable<StorageFile>
toIEnumerable<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
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.
The text was updated successfully, but these errors were encountered: