Peter Huene

Hi @martindevans, sorry for the delay in reviewing this! These changes look good, only I'm having a hard time thinking about the real world use case that would necessitate the...

Ping @richlander. It'd be nice to have this for the 2.1 RTM SDK images. Users will expect that `/root/.dotnet/tools` to be on `PATH` if they're playing around with global tools...

Perhaps we could use `/etc/profile.d` like we do when you install the SDK via the installer? It creates `/etc/profile.d/dotnet-cli-tools-bin-path.sh` with the contents: ``` export PATH="$PATH:~/.dotnet/tools" ```

Either suggestion should work provided bash is the shell being used 👍 I forgot that bash does expand tilde when searching `PATH` (zsh does not, which is what I use).

Do we want `/usr/share/dotnet` instead of perhaps `/var/cache/dotnet`? To me, the former is not something we'd want users to delete to "clear out" because it is the install directory for...

I think so.

The observation is expected when using `DOTNET_CLI_HOME`, since the installers will, at best, add `~/.dotnet/tools` only to the PATH. If we've set `DOTNET_CLI_HOME` to `/var/cache`, then I'd also add `/var/cache/.dotnet/tools`...

Hi @hiinaspace: The intention behind this is that `externref` is a *reference* to an external (host) object, so it is intentionally limiting the support for .NET types to those that...

At a bare minimum, we should improve this exception message to note that it's because the type is a value type and .NET types are required to be reference types...

Hi @NewGyu, thanks for reporting this issue! Currently `cargo-component` expects a dependency specified by path to be to a component wasm and not a WIT file (or an binary-encoded WIT...