Esme

Funny you should mention Wine, we still have to support .NET Framework applications, and we use (a fork of) Mono to do that. But for .NET 5 it seems like...

It sounds like it's one of the few remaining use cases for Mono as a .NET Framework implementation specifically, where you wouldn't ideally want a newer version of .NET.

What if we added a new constant `MONO_TYPE_UNRESOLVED_CLASS` to represent a class that hasn't been loaded yet? Then, similar to what we do with custom attrs, by default doing anything...

Is the code that adds the AssemblyResolve handler on the class that has the unresolved field? If not, it might be some other load-order bug.

Hi, this is technically not an XNA game as it ships and uses MonoGame (same/similar API, different implementation). It is using wine-mono so it's very possible that's related. But just...

ILSpy shows that it's using reflection to try to access a private field of the IsolatedStorageFile class named m_RootDir, which doesn't exist in Mono's implementation of IsolatedStorageFile. This is in...

Mono's implementation uses a private DirectoryInfo field named directory for this.

It's possible to work around that error by adding a m_RootDir field that mirrors directory, but after that I run into a file sharing conflict trying to read the mp3.

Whoops, the conflict is actually in trying to delete the mp3. I think it's because our MFCreateFile function doesn't use the FILE_SHARE_DELETE flag when opening the file.

Those two changes are enough to get music working. I used this patch to Wine: ``` diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c index ff7155b5ade..58bfccb7264 100644 --- a/dlls/mfplat/main.c +++ b/dlls/mfplat/main.c @@ -4422,7 +4422,7...