Host tracing using hostfxr_set_trace_listener

[jozefizso]

The .NET 6 documentation for tracing the native hosting using hostfxr mentions the hostfxr_set_trace_listener() function which is used to provide tracing implementation.

Host tracing documentation: https://github.com/dotnet/runtime/blob/release/6.0/docs/design/features/host-tracing.md

I cannot find the function the the nethost.h header file, nor anywhere in the runtime repo.

Is this API available?

[am11]

Looks like the closest available API is corehost_set_error_writer.

@vitek-karas, I think hostfxr_set_trace_listener can be removed from docs as it was not implemented as proposed. Regarding corehost_set_error_writer, is it intentional that user-provided callback is not allowed to capture warning, info and trace severity logs (value is ultimately only used by trace::error)?

runtime/src/native/corehost/hostmisc/trace.cpp

Line 143 in bbc898f

g_error_writer(buffer.data());

[vitek-karas]

Thanks @am11 for the reply, it's spot on.

The document host-tracing.md is out of date. Its content currently is the proposal for what we wanted to do in .NET Core 3. We ended up with somewhat different implementation eventually.

I'm updating the doc here: #67749

Currently it's by-design that only errors can be redirected in code. We simply didn't have a need for a fully customizable tracing in code.

The right API to use is hostfxr_set_error_writer for custom hosts pretty right after loading hostfxr. hostpolicy does expose corehost_set_error_writer but hostpolicy should really only be used by hostfxr or the runtime, so custom hosts should not call into it directly.

The nethost library currently doesn't support error redirection (it doesn't output errors anywhere, if tracing is enabled the errors will be part of the tracing output).

[jozefizso]

The current design to enable tracing using env variables does not quite work for our hosting scenario (inside a desktop application). We would like to control the tracing from the code. The hostfx listener was a perfect fit for us to provide our own logging implementation.

As we need to troubleshoot hostfxr loading, it is too late to set hostfxr_set_error_writer after the hostfxr is loaded.

[vitek-karas]

Can you maybe describe the scenario in more detail? I must admit I don't understand what you're trying to do.

If you have a custom host, then you control loading of hostfxr and thus can set the error writer. You can also set the env. variables before calling into the hostfxr for the first time from your host. It's not super clean, but if you redirect tracing to some temp file it's effectively invisible to the user.

If you don't have a custom host and use either dotnet.exe or the generated app.exe then where would you want to use the callbacks to redirect tracing? Inside the managed code of the app is already too late as hostfxr has already been loaded (and if you're having issues with that, it won't even run anyway). So you need some mechanism which acts on the process as a whole. Currently the hosting components only support env. variables for this purpose.

Note that on Windows the errors are also written into the event log, so you can get some information (not the full trace, but at least something) from the event log. This is done by default, no need to enable anything.

[jozefizso]

We have experience with running apps in corporate environments which may limit what apps are allowed to do. Effectively there are antivirus solutions that try to sandbox apps in various ways.

To troubleshoot such problems, we need built in API which allows us capture tracing of what is happening in the hostfxr. Although setting env variables before we run the app on development PC is fine, it does not really work in production. Also we would like to integrate the logging into the OS provided logging API instead of the file. The trace listener is a great fit for this.

This is the error we got from the int rc = get_hostfxr_path(buffer, &buffer_size, &params); call: 0x80008083 (it is CoreHostLibMissingFailure) - it is impossible to tell what is happening without the trace.

The trace showed this:

Reading fx resolver directory=[/usr/local/share/dotnet/host/fxr]
A fatal error occurred, the folder [/usr/local/share/dotnet/host/fxr] does not contain any version-numbered child folders

Because of the sandboxing of the host app, the hostfxr loader cannot enumerate the content of the fxr folder. There are two .NET runtimes installed and yet the application cannot see them. We are developing the correct logging for such scenarios where the system is "misconfigured" from expected permissions.

[vitek-karas]

The only way I can think of doing this is using custom host - then you can use the error writer redirection. It would at least give you the last line of the trace (that is written as error and so would go through the error writer).

I must admit we didn't look into providing OS-supported tracing/error logging on linux (basically the counterpart to writing to event log on Windows). Maybe there's something reasonably standard across linuxes to do this.

Curious if you have experience with this - how other applications do this? How do they expose tracing capabilities which would work for you?