NativeAOT publish for DLL does not set automatically RID

[kant2002]

I was have following setup. DLL project which I publish as NativeAOT. I have to publish it dotnet publish -r win-x64 --self-contained otherwise project does not pickup nor current RID of my dev machine, not the fact that application is self-contained (NativeAOT). It's most likely issue in SDK

• dotnet publish want me specify RID
• dotnet publish -r win-x64 use WinForms references during build, but do not propagate them for publish to ILC
• dotnet publish -r win-x64 --self-contained works, but self-contained switch is misleading probably and undo a lot of tooling work in recent releases around NativeAOT

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I was have following setup. DLL project which I publish as NativeAOT. I have to publish it dotnet publish -r win-x64 --self-contained otherwise project does not pickup nor current RID of my dev machine, not the fact that application is self-contained (NativeAOT). It's most likely issue in SDK

• dotnet publish want me specify RID
• dotnet publish -r win-x64 use WinForms references during build, but do not propagate them for publish to ILC
• dotnet publish -r win-x64 --self-contained works, but self-contained switch is misleading probably and undo a lot of tooling work in recent releases around NativeAOT

Author:	kant2002
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[am11]

In .NET 7+, dotnet-publish sets the RID implicitly to the runtime of executing dotnet.exe with Publish{Aot,SingleFile,ReadyToRun}.

You can also pass --use-current-runtime or --ucr in a general-purpose script (e.g. for CI) for cases which aren't covered by implicit RID. I don't remember offhand which are those cases, @nagilson might.

dotnet new mvc -n mvc1 && dotnet publish -p:PublishAot=true mvc1 publishes AOT app for win-x64 on Windows 10 x64 machine; without explicitly specifying the runtime with .NET 7 (and 8 alpha).

[kant2002]

I know about that, but if you create

dotnet new winforms 
# remove OutputType
dotnet publish

then you will have situation like I describe. Probably MVC is special cased somehow.

[am11]

Well, I tested with two templates: Console and MVC. WinForms is rather an exception.

dotnet new winforms 
# remove OutputType
dotnet publish

I don't see PublishAot specified anywhere.

[kant2002]

You may take a look at this project https://github.com/kant2002/WinFormsComInterop/blob/main/samples/HostedWindowsForms/HostedWindowsForms.csproj

which was led to following error kant2002/WinFormsComInterop#48 (comment) if using dotnet publish -r win-64.

[kant2002]

I think issue is specifically for OutpuType=Library kind of projects. That maybe by design in regular CoreCLR publish, but unexpected for NativeAOT

[am11]

Yes, classlib requires the runtime argument:

$ dotnet new classlib -n lib1
$ dotnet publish lib1 -p:PublishAot=true --use-current-runtime

[kant2002]

I see two problems here, why PublishAot does not imply --use-current-runtime and second. Why PublishAot does not imply --self-contained. I may probably understand some rationale for first case, but not for second.

[am11]

Your sample https://github.com/kant2002/WinFormsComInterop/tree/main/samples/HostedWindowsForms is building on my Win10 box with .NET SDK 7.0.101 without --self-contained:

dotnet publish --use-current-runtime
::: or
dotnet publish -r win-x64

...
Generating native code
...

produces bin\Debug\net7.0-windows\win-x64\publish\HostedWindowsForms.dll which is a native library according to ildasm.exe.

[kant2002]

I belive you are did not notice ILC: Method '[HostedWindowsForms]HostedWindowsForms.LibraryFunctions.ShowMessageBox()' will always throw because: Fai led to load assembly 'System.Windows.Forms' . that's because System.Windows.Forms.dll is not part of set of published files. And that's because dotnet SDK think this is not self-contained app.

[am11]

ILC: Method '[HostedWindowsForms]HostedWindowsForms.LibraryFunctions.ShowMessageBox()' will always throw because: Fai led to load assembly 'System.Windows.Forms'

Sounds like this should be an error.

[kant2002]

ILC reporting is separate issue. I'm worry only about SDK behavior. It seems reasonable that if PublishAot=true then SDK infer RID and --self-contained independently from OutputType of the project.

[MichalStrehovsky]

This is probably because publishing a library mostly works by accident in the SDK and wasn't fully tested for everything. dotnet/linker#3165 (comment). Looks like it doesn't even work for all NativeAOT scenarios (although WinForms with NativeAOT is definitely not a supported scenario in 7.0).

ILC: Method '[HostedWindowsForms]HostedWindowsForms.LibraryFunctions.ShowMessageBox()' will always throw because: Fai led to load assembly 'System.Windows.Forms'

Sounds like this should be an error.

Nope, people add assemblies their grandmother wrote for .NET Framework 1.0 to their .NET 7 apps and expect the parts that work with a JIT-based runtime to also work on an AOT-based runtime. (I.e. publishing apps with missing or mismatched dependencies is common so the compiler makes a reasonable attempt to emulate the JIT behavior where one would get an exception only once a problematic codepath is reached.)

[kant2002]

So we have one more case in addition to Android where publish self-contained libraries make sense. Is this should be better documented in sample, or SDK work?