[ Microsoft.DotNet.ILCompiler ] "COM Interop is not supported on this platform" exception after updating to new version of package

[FoggyFinder]

Didn't change anything except

<PackageReference Include="Microsoft.DotNet.ILCompiler" Version="1.0.0-alpha-*" />

->

<PackageReference Include="Microsoft.DotNet.ILCompiler" Version="6.0.0-*" />

App uses Avalonia 0.9.11

part of StackTrace

Unhandled Exception: System.PlatformNotSupportedException: COM Interop is not supported on this platform.
   at Internal.Runtime.CompilerHelpers.InteropHelpers.ConvertManagedComInterfaceToNative(Object) + 0x42
   at Avalonia.Win32.Interop.UnmanagedMethods.RegisterDragDrop(IntPtr, IDropTarget) + 0x46
   at Avalonia.Win32.OleContext.RegisterDragDrop(IPlatformHandle, IDropTarget) + 0x68
   at Avalonia.Win32.WindowImpl.CreateDropTarget() + 0x43
   at Avalonia.Controls.TopLevel..ctor(ITopLevelImpl, IAvaloniaDependencyResolver) + 0x1ac
   at Avalonia.Controls.WindowBase..ctor(IWindowBaseImpl, IAvaloniaDependencyResolver) + 0x24
   at Avalonia.Controls.Window..ctor(IWindowImpl) + 0x62

[jkotas]

The COM interop has not been supported by CoreRT. It is not clear to me how this could ever work.

[FoggyFinder]

Yeah, that's odd.

I tried to reproduce on AvaloniaCoreRTDemo. It works just fine for 1.0.0-* (with small adjustment) but I even wasn't able to build the project with 6.0.0.-*

I'm getting

Compiling [S.P.TypeLoader]System.Collections.Generic.LowLevelDictionary`2<Internal.Runtime.TypeLoader.TypeLoaderEnvironment+RuntimeFieldHandleKey,System.RuntimeFieldHandle>.ExpandBuckets()...
EXEC : LLVM error : IO failure on output stream. [...\AvaloniaCoreRTDemo.csproj]

[josephmoresena]

Yeah, that's odd.

I tried to reproduce on AvaloniaCoreRTDemo. It works just fine for 1.0.0-* (with small adjustment) but I even wasn't able to build the project with 6.0.0.-*

I'm getting

Compiling [S.P.TypeLoader]System.Collections.Generic.LowLevelDictionary`2<Internal.Runtime.TypeLoader.TypeLoaderEnvironment+RuntimeFieldHandleKey,System.RuntimeFieldHandle>.ExpandBuckets()...
EXEC : LLVM error : IO failure on output stream. [...\AvaloniaCoreRTDemo.csproj]

Try to use
<TargetFramework>netcoreapp3.1</TargetFramework> <Platforms>x64</Platforms>
instead of
<TargetFramework>net5.0</TargetFramework> <Platforms>AnyCPU;x64</Platforms>
Seems new Avalonia version doesn't work with CoreRT nor NativeAOT.

[FoggyFinder]

Try to use <TargetFramework>netcoreapp3.1</TargetFramework> <Platforms>x64</Platforms>

I had removed this line at all.
I tried to specify <Platforms>x64</Platforms> and result is even worse. I get an exception and after than system gets crazy. Many launched applications are stopped to respond. And those that didn't are getted blurry. I had to restart system completely.

I was able to make a screenshot though:

Seems new Avalonia version doesn't work with CoreRT nor NativeAOT.

yeah. Seems like I will stick to good old CoreRt and Avalonia 0.9.11.

[josephmoresena]

Try to use <TargetFramework>netcoreapp3.1</TargetFramework> <Platforms>x64</Platforms>

I had removed this line at all.
I tried to specify <Platforms>x64</Platforms> and result is even worse. I get an exception and after than system gets crazy. Many launched applications are stopped to respond. And those that didn't are getted blurry. I had to restart system completely.

I was able to make a screenshot though:

Seems new Avalonia version doesn't work with CoreRT nor NativeAOT.

yeah. Seems like I will stick to good old CoreRt and Avalonia 0.9.11.

Weird, what windows version are you using? I'm running W10 LTSC 2020.

Framework version is 6.0 according to Native AOT, when use latest old CoreRT Framework version says

[FoggyFinder]

Weird, what windows version are you using?

10.0.17763

[jkotas]

I have submitted PR to update AvaloniaCoreRTDemo to the new nuget feed: teobugslayer/AvaloniaCoreRTDemo#4 . It works fine for me.

[josephmoresena]

Weird, what windows version are you using?

10.0.17763

I have the same version. I attached a detailed log by executing `dotnet publish -r win-x64 -c release -v d >> log.txt may it help.
log.txt

[jkotas]

We have fixed a crash in FinishObjWriter a few weeks ago. Maybe you are not using the latest package?

[FoggyFinder]

We have fixed a crash in FinishObjWriter a few weeks ago. Maybe you are not using the latest package?

How can I make sure I'm on latest?

I have 3 packages:

6.0.0-alpha.1.20531.1 (probably the one where I got FinishObjWriter crash
6.0.0-alpha.1.20527.1 (probably the one where I saw System.PlatformNotSupportedException exception described in started post)

old one: CoreRt (works great)

1.0.0-alpha-29408-02

[FoggyFinder]

I attached a detailed log by executing `dotnet publish -r win-x64 -c release -v d >> log.txt may it help.

dunno. I use these settings in a fsproj/csproj

  <ItemGroup>
    <IlcArg Include="--verbose" />
    <IlcArg Include="--singlethreaded" />
  </ItemGroup>

to get more informative logs.

[jkotas]

Both these are very recent (20527.1 is October 27, 20531.1 is October 31). I am running out of ideas why it may be crashing for you.

[FoggyFinder]

I had an idea.
CoreRtDemo project was on system disk (C) while my application was on a different one.

So I moved CoreRtDemo to another one and now there is no crash and it started just fine (after I copied images near .exe).

[FoggyFinder]

since it works OK on demo project I'll try to create MCVE. I can only hope it won't be too complicated

[FoggyFinder]

@jkotas why the issuw was closed? Cause there is no way to reproduce?

[jkotas]

If you are still not able to figure why things that used to work with the CoreRT package do not work anymore, I will be happy to reactive this issue.

I have created a dedicated issues for the COM interop support since it is a popular topic: #306

[FoggyFinder]

If you are still not able to figure why things that used to work with the CoreRT package do not work anymore, I will be happy to reactive this issue.

Yep, no idea. I tried to create MCVE but for some reason my attempt is crashed horribly with "hard error" exception during the first "Generating native code" task even with old version of CoreRt.

Initally I thought it is coincidnce and might be unrelated to CoreRt but when I repeat test (this time I turned off almost all applications) and got the same crash I decide to stop.

I'll try find another machine to confirm crash on test project.

But for the main issue I will have to minimize my project step by step so it will take longer. I'll try to do it on weekend.

New version of CoreRt produces bigger executable (+8Mb for my project). Maybe it keeps some methods that were stripped away previously despite they're unused?

[jkotas]

Maybe it keeps some methods that were stripped away previously despite they're unused?

The compiler logic that controls what is stripped have not changed. If you see this, it must be caused by some secondary effect like implementation change in one of the libraries.