Create native host for application with only runtime installed

[QuarterYang]

Currently we need to build or publish multiple times to generate native host for each target platform, which is not convinient. I discovered that CLI command 'dotnet tool install' would generate a current platform native host for tools installed using AppHost template for current platform. Is there any chance to support generate native AppHost with only Runtime installed by run a command in CLI.

For example, run command dotnet create-host <path to app.dll> to generate native host for specific application.

It would be simple to build/ship application running on multi-platform. Developers could simply build and publish application without native host and just run same command during installation on any platform with dotnet runtime installed.

[dotnet-policy-service]

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

[huoyaoyuan]

Note that the dotnet CLI commands, including dotnet tool, belong to SDK. The runtime-only version of dotnet.exe only has the ability to find and load the correct version of CLR. It can't execute any custom command.

Is there any chance to support generate native AppHost with only Runtime installed by run a command in CLI.

There's no "command in CLI" at all without SDK installed. It's also questionable to produce executable files without SDK.

For example, run command dotnet create-host <path to app.dll> to generate native host for specific application.

Generating executable files is not as simple as you may think. Currently, generating the most-correct executable requires running SDK on the same platform. It's even not perfect to do cross-publish. See dotnet/sdk#3943 dotnet/sdk#34917. There are many issues like native resource processing and code signing/notarization.

[huoyaoyuan]

Other things to consider:

• It's widely considered malicious to create executable files. The well-known developer tools can be exempt from this.
• At the view of end user, executing a command may be more complex than creating a shortcut for dotnet.exe app.dll.

[QuarterYang]

Note that the dotnet CLI commands, including dotnet tool, belong to SDK. The runtime-only version of dotnet.exe only has the ability to find and load the correct version of CLR. It can't execute any custom command.

That‘s helpful, thx. Is there any similar interface available without SDK?

While currently I'm planing to make a console app as a host-creation-tool which depending on something like Microsoft.NET.HostModel and AppHost(with .exe on windows) just like what CreateAppHost task do. But the native host I'm going to implement is almost the same thing as AppHost in the runtime. But if depending on Microsoft.NET.HostModel directly the console app would need to include the AppHost template for different OS and instruction set, which is already included in SDK for every platform. On linux distributions like debian/centos, I could simply pack the host-creation-tool as a deb/rpm and make it depend on dotnet-apphost-pack-[major].[minor] to include AppHost template, but I'm not sure would there be any similar package on any other platform.

• It's widely considered malicious to create executable files. The well-known developer tools can be exempt from this.

Currently I'm not familiar about things related to anti-various, but I believe there would not be too much difference between using dotnet(.exe) and using another native host.

• At the view of end user, executing a command may be more complex than creating a shortcut for dotnet.exe app.dll.

Script could be executed automatically during installation in many application/package manager. Even without the support of application/package manager embeding a command into installation process should not be complicated.
Thouthg I'm not sure about it but I think shotcut should be something platform specific, so I prefer using native host to depending on it.

[huoyaoyuan]

But if depending on Microsoft.NET.HostModel directly the console app would need to include the AppHost template for different OS and instruction set, which is already included in SDK for every platform. On linux distributions like debian/centos, I could simply pack the host-creation-tool as a deb/rpm and make it depend on dotnet-apphost-pack-[major].[minor] to include AppHost template, but I'm not sure would there be any similar package on any other platform.

So you are requesting as subset of SDK that's necessary to build native host, without bringing full SDK.

Currently I'm not familiar about things related to anti-various, but I believe there would not be too much difference between using dotnet(.exe) and using another native host.

dotnet.exe is created by some trusted source, for example Microsoft build server, or Linux distro build, with corresponding digital signature from Microsoft/distro owner.
The published executable from developer machine is similar to custom host. However, the context of developer's machine and end user's machine are different. It's usually considered more restricted on end user's machine. The creation of executable files should be done on developer's machine.

Script could be executed automatically during installation in many application/package manager.

When creating packages for installers, you are already creating platform dependent content. It's easy to access SDKs on the machine that creates packages.

Thouthg I'm not sure about it but I think shotcut should be something platform specific, so I prefer using native host to depending on it.

Executable files are much more platform-dependent and risky.

[QuarterYang]

So you are requesting as subset of SDK that's necessary to build native host, without bringing full SDK.

Right. And native code of that subset is actually maintained under /src/native/corehost/ in the runtime repo.

When creating packages for installers, you are already creating platform dependent content. It's easy to access SDKs on the machine that creates packages.

I don't think so. Operating systems like linux/bsd might run on machines with instruction set that was not included during building. And it's not necessary publishing application multiple times for every platform including a native entry. That's the reason I'm planing to implement the host-creation-tool.

dotnet.exe is created by some trusted source, for example Microsoft build server, or Linux distro build, with corresponding digital signature from Microsoft/distro owner. The published executable from developer machine is similar to custom host. However, the context of developer's machine and end user's machine are different. It's usually considered more restricted on end user's machine. The creation of executable files should be done on developer's machine.

Executable files are much more platform-dependent and risky.

I agree. So I feel it's better including AppHost in release of runtime rather than only including it in SDK. Then it will be easy to include nuget package Microsoft.NET.HostModel and implement a tool(a console/commandline tool or anything else) generating native host for applications on any platform with runtime installed.

[huoyaoyuan]

Operating systems like linux/bsd might run on machines with instruction set that was not included during building.

The architecture doesn't need to match for publishing. You can publish for win-arm64 on win-x64 for sure.

And it's not necessary publishing application multiple times for every platform including a native entry.

It is often very necessary, if you want to enable optimizations like R2R or trimming, or native AOT publishing. Native dependencies will also be re-organized during publishing.

So I feel it's better including AppHost in release of runtime rather than only including it in SDK.

generating native host for applications on any platform with runtime installed.

It does not change the risk to do these on end user's machine.

---

The app host templates are available as NuGet packages Microsoft.NETCore.App.Host.<rid>.