-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a hostfxr
API for resolving runtime frameworks
#99027
Comments
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsThere 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 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:
|
@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. |
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. |
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 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. |
Maybe
That is what the |
Slight cleanup of `fx_resolver_t` and `NativeHostApis` tests in preparation for #99027: - Collapse `reconcile_fx_references_helper` into `reconcile_fx_references` - Make `NativeHostApis` tests / `HostApiInvokerApp` more consistent in how they log and validate results
Slight cleanup of `fx_resolver_t` and `NativeHostApis` tests in preparation for dotnet#99027: - Collapse `reconcile_fx_references_helper` into `reconcile_fx_references` - Make `NativeHostApis` tests / `HostApiInvokerApp` more consistent in how they log and validate results
Slight cleanup of `fx_resolver_t` and `NativeHostApis` tests in preparation for dotnet#99027: - Collapse `reconcile_fx_references_helper` into `reconcile_fx_references` - Make `NativeHostApis` tests / `HostApiInvokerApp` more consistent in how they log and validate results
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 tohostfxr_resolve_sdk
. Something like:Related:
cc @agocke @JL03-Yue
The text was updated successfully, but these errors were encountered: