Provide a `hostfxr` API for resolving runtime frameworks

[elinor-fung]

There is currently no way to run the host's runtime framework resolution algorithm in an isolated manner. This can be helpful for doing things like determining whether an application would be able to run on the current environment.

We could add a hostfxr_resolve_runtime_frameworks that acts as a parallel to hostfxr_resolve_sdk. Something like:

struct hostfxr_framework_result
{
    size_t size;
    const char_t* name;
    const char_t* requested_version;
    const char_t* resolved_version;
    const char_t* resolved_path;
};

struct hostfxr_resolve_frameworks_result
{
    size_t size;

    size_t resolved_count;
    const struct framework_result* resolved_frameworks;

    size_t unresolved_count;
    const struct framework_result* unresolved_frameworks;
};

typedef void (*hostfxr_resolve_frameworks_result_fn)(
    const hostfxr_resolve_frameworks_result* result,
    void* result_context);

// runtime_config_path : path to the runtime config file
// parameters          : additional parameters for initialization
//                       if null or dotnet_root is null, the root corresponding to the running hostfxr is used
// callback            : invoked with the result of the resolution
// result_context      : additional context passed to the callback
int32_t hostfxr_resolve_frameworks_for_runtime_config(
    const char_t* runtime_config_path,
    /*opt*/ const hostfxr_initialize_parameters* parameters,
    /*opt*/ hostfxr_resolve_frameworks_result_fn callback,
    /*opt*/ void* result_context);

Related:

• [Proposal] .NET Tools should default to running on the latest available Runtime sdk#30336
• Programmatically resolving shared frameworks #3412

cc @agocke @JL03-Yue

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

There is currently no way to run the host's runtime framework resolution algorithm in an isolated manner. This can be helpful for doing things like determining whether an application would be able to run on the current environment.

We could add a hostfxr_resolve_runtime_frameworks that acts as a parallel to hostfxr_resolve_sdk. Something like:

struct framework_result
{
    size_t size;
    const char_t* name;
    const char_t* requested_version;
    const char_t* resolved_version;
    const char_t* resolved_path;
};

struct hostfxr_resolve_framework_result
{
    size_t size;

    size_t resolved_count;
    const struct framework_result* resolved_frameworks;

    size_t missing_count;
    const struct framework_result* missing_frameworks;
};

typedef void (*hostfxr_resolve_frameworks_fn)(
    const hostfxr_resolve_framework_result* result,
    void* result_context);

// runtime_config_path : path to the runtime config file
// parameters          : additional parameters for initialization
// callback            : invoked with the result of the resolution
// result_context      : additional context passed to the callback
int32_t hostfxr_resolve_runtime_frameworks(
    const char_t* runtime_config_path,
    /*opt*/ const hostfxr_initialize_parameters* parameters,
    /*opt*/ hostfxr_resolve_frameworks_fn callback,
    /*opt*/ void* result_context);

Related:

• [Proposal] .NET Tools should default to running on the latest available Runtime sdk#30336
• Programmatically resolving shared frameworks #3412

cc @agocke @JL03-Yue

Author:	elinor-fung
Assignees:	-
Labels:	area-Host
Milestone:	9.0.0

[JL03-Yue]

@elinor-fung Thank you so much for putting up the issue. I would love to keep this updated and keep following up with the issue.

[vitek-karas]

Looks great to me.

For future considerations - I vaguely remember scenarios where this would help if the input was not a file but some in-memory data structure describing the required dependencies. I think WiX installers wanted something like that - workaround is to write a temp config file to disk, but that's obviously not ideal.

[jkoritzinsky]

I had a scenario where I don't have a runtimeconfig file on disk and would like to use this API. I'm currently using hostfxr_get_dotnet_environment_info to get something that works. (code is at https://github.com/AaronRobinsonMSFT/DNMD/blob/master/test/regpal/pal.cpp#L154).

Especially having an API that operates on the installation/layout that the hostfxr is present in when unspecified instead of the global installation would be very useful.

[elinor-fung]

For future considerations - I vaguely remember scenarios where this would help if the input was not a file but some in-memory data structure describing the required dependencies.

Maybe hostfxr_resolve_runtime_frameworks -> hostfxr_resolve_frameworks_for_runtime_config for this one then. So we don't have to figure out some horrible name for an in-memory data structure version.

Especially having an API that operates on the installation/layout that the hostfxr is present in when unspecified instead of the global installation would be very useful.

That is what the hostfxr_initialize_* functions do. I think it would be reasonable for this one to do the same. For the functions for getting environment information like hostfxr_get_dotnet_environment_info and hostfxr_get_available_sdks, I could see having some sentinel value that could be passed as dotnet_root to indicate that the running hostfxr should be used.