runtime: The new nethost static library is not published in the daily builds
I’m trying to use the new nethost static library that was introduced via #296.
Since I have yet to figure out how to use NuGet packages like Microsoft.NETCore.DotNetAppHost (or Microsoft.NETCore.App.Host.[win-x64|linux-x64] ) from native C builds I tried to download the daily releases (https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-nethost-latest-win-x64.zip or https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/dotnet-nethost-latest-linux-x64.tar.gz) where I found out that the static libraries don’t get published.
Is this an intentional decision or an oversight?
If it is an intentional decision, this might be a documentation issue. How am I supposed to consume the NuGet packages and are there daily builds of them? I’ve already read https://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting and https://github.com/dotnet/runtime/blob/master/docs/design/features/native-hosting.md and also tried https://github.com/dotnet/samples/tree/master/core/hosting/HostWithHostFxr but all of them don’t show an elegant or recommended way of using them. The samples actually show a way which is described as “relatively complicated” and recommend CMake for native builds which, to my knowledge, can’t consume NuGet packages.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 27 (23 by maintainers)
@Brar My mistake. I meant to say “it is now”. I fixed this issue in #35431. Adding testing for the scenario is all that remains.
@VSadov I am trying to leave files where they are. However, the CMake files for corehost need a lot of attention. They are in an unacceptable state and make reasoning about this so much harder than they should be for such a simple set of build requirements like corehost.
I think it is fine to revert https://github.com/dotnet/runtime/pull/2123. The static host PR will need to merge appropriately, but @VSadov is looking at making changes to the file-moves in the PR anyways. So I think it’ll be OK to adapt to the change. CC:@VSadov
My vote would be to revert #2123 . Building a couple of .cpp files twice is just fine.
@am11 unfortunately no, the infra that was doing that is very brittle vs. Arcade breaking changes, so we decided to wait for https://github.com/dotnet/arcade/issues/3963 instead of bringing the old infra online in the new dotnet/runtime repo.