That dotnet
is provided by both sdk and runtime is by design and matches the construction of our other deployment constructions (deb, rpm, msi, zip, tar, …). By default, the runtime and sdk native installers install into the same product root. There are a few other directories but this should explain the layout:
/dotnet
dotnet (this is the executable under discussion)
/host
/sdk (can have side-by-side versions)
/2.0.0
/shared (shared runtime libraries)
/Microsoft.NETCore.App (can be any number of side-by-side versions with our 'regular' installs)
/2.0.0
The combination of the dotnet
executable and host activation policy found under /host determine which runtime to utilize for a given portable application. Where all of the functional components of the install can be versioned side-by-side, dotnet
is a single shared entry point.
I agree that a snap install complicates matters a bit in that runtime and sdk are installed as separate units rather than layered in the same directory. Generally, the SDK is the single entry point for developer usage where as the runtime would be used for application deployment so I think we could mitigate somewhat with documentation. Having the SDK utilize an installed Runtime via content interface is a really interesting idea but would result in the Snap offering being quite different in construction from our other acquisition artifacts.