Remove Microsoft.NETCore.DotNetHost NuGet packages

[eerhardt]

We are still building and shipping:

• Microsoft.NETCore.DotNetHost
• Microsoft.NETCore.DotNetHostPolicy
• Microsoft.NETCore.DotNetHostResolver

NuGet packages. See https://www.nuget.org/packages/Microsoft.NETCore.DotNetHostPolicy/5.0.0-preview.2.20160.6.

These packages shouldn't be used anymore since customers get these assets through runtime packs. (You can see this by looking at the massive dropoff in downloads between 2.x and 3.x versions.) We should stop shipping these packages, and should probably stop building them all together.

cc @ericstj @dagood @vitek-karas

[ghost]

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

[vitek-karas]

The Microsoft.NETCore.DotNetHost package is currently the "official" source of the "nethost.dll" which is used for native hosting scenarios. See https://github.com/dotnet/samples/tree/master/core/hosting/HostWithHostFxr#key-features.

There is another way via vcpkg: #3774, but that is a bit weird for some Linux/MacOS scenarios.

There was a discussion on what does it mean to ship native build assets, but so far no conclusion.

[rseanhall]

I would like these packages to stay. In fact, I wish they included the header files hostfxr.h, coreclr_delegates.h, and coreclrhost.h. And potentially the static libs for hostfxr and hostpolicy.

[vitek-karas]

Curious: by static libs you mean the .lib file so that it's easy to consume a .dll on Windows, or real static libs which contain the actual code?

What for? Do you want to replicate single-file (cause that's basically the only scenario I can think of which would need statically linked hostfxr and hostpolicy)? I'm really just curious.

[rseanhall]

Actual code. This could allow me to ignore old versions of hostfxr on the machine and use the newer functionality, like what we're currently discussing at #35465.

I wouldn't actually use hostpolicy, maybe there's no good reason for that.

[vitek-karas]

I can see hostfxr like that (could be a separate dll in your case, but statically linked would be nicer I guess).

But honestly hostpolicy should never be tied like that. hostpolicy is basically part of the runtime and it should be versioned along with it - that is the hostpolicy -> runtime interface may be version fragile (we try not to do this, but we could).

[rseanhall]

What is the status of this? I want to add hostfxr.h and coreclr_delegates.h to the Microsoft.NETCore.DotNetHost package, but won't bother if it will be deleted. Should I create a new issue for adding those header files to it?

[vitek-karas]

I don't think we made any decision on this yet. If we do stop producing these packages we would have to introduce a new package (or some other way) to ship the native build assets (headers, libs, ...).

I think that it makes sense to add the header files. And when/if we move the native build assets elsewhere we would take those along.

[b8adamson]

I may be misunderstanding how to use these DotNetHost, DotNetAppHost and DotNetAppHostResolver packages, but they seem to be empty? I was expecting they would at least contain nethost.dll? So FWIW I'm a user who can't figure out how to use them and it seems I might have been better off if they didn't exist as I would have just manually added nethost.dll to my own nuspec.

[vitek-karas]

The package which contains nethost.dll is Microsoft.NETCore.DotNetAppHost. Please note that it's a metapackage, it contains references to the RID specific packages which actually contain the files. This is also described here: https://github.com/dotnet/samples/tree/main/core/hosting/HostWithHostFxr#key-features

So for example for win-x64, the package which actually contains the files is runtime.win-x64.Microsoft.NETCore.DotNetAppHost.

[vitek-karas]

As for this issue - I actually originally misread it. @eerhardt is correct that there seems to be no need for:
Microsoft.NETCore.DotNetHost (contains just dotnet.exe)
Microsoft.NETCore.DotNetHostPolicy (contains just hostpolicy.dll)
Microsoft.NETCore.DotNetHostResolver (contains just hostfxr.dll)

The only package we should keep is Microsoft.NETCore.DotNetAppHost (contains apphost, singlefilehost, nethost, ijwhost, comhost and related header files).

[agocke]

Should be fixed by #71725

[elinor-fung]

@agocke did that change do anything with how we publish dotnet and hostpolicy symbols? I don't know if it was the case anymore, but we used to be relying on the symbol packages for Microsoft.NETCore.DotNetHost and Microsoft.NETCore.DotNetHostPolicy to get symbols for dotnet and hostpolicy published.

[agocke]

Ah, it removed some of those packages, but Microsoft.NETCore.DotNetHost should still be published, which contains dotnet, hostpolicy, and hostfxr.

Nvm, wrong files. It removed those packages, so we may need some other vehicle.

[agocke]

Actually, I think we can re-add the package publishing without any big problems.