Skip to content
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

v4: Review "Available Frameworks" functionality in view of pluggable agents #887

Open
ChrisMaddock opened this issue Jan 30, 2021 · 2 comments

Comments

@ChrisMaddock
Copy link
Member

Currently the engine must know about all available frameworks, to expose a list via the RuntimeFrameworkService to a runner, and validate the RequestedRuntimeFramework option.

This is a source of technical debt and a maintenance requirement for a number of legacy runtimes, and new runtimes that become available. We need to decide what this functionality would look like in a world of dynamic runtime availability and pluggable agents. Should the agent be responsible for announcing what frameworks it can run on?

@CharliePoole
Copy link
Contributor

In the GUI, I expose this as a menu, which gets uncomfortably long on my machine because so much stuff is installed - also because I list each possible version of CLR4 framework available.

I'm planning to change that to list the available agents, both built-in and pluggable.

Maybe that's what the engine should support externally either in addition to or instead of the available runtimes.

In fact, my experimentation with pluggable agents showed me that the agent needs to know what runtimes it can run on., so making this an agent responsibility is sensible. Also, if we implement agents that run on other machines, then only the agent will be able to fulfill that role.

All that said... it's really pretty hard to think about this without knowing what will happen with the proposed elimination of both processmodel and domainusage selection. If we do both of those things, then it gets easier.

@ChrisMaddock ChrisMaddock added this to the 4.0 milestone Jan 30, 2021
@ChrisMaddock
Copy link
Member Author

In fact, my experimentation with pluggable agents showed me that the agent needs to know what runtimes it can run on., so making this an agent responsibility is sensible. Also, if we implement agents that run on other machines, then only the agent will be able to fulfill that role.

This makes a lot of sense. So the engine should ask all installed agents which runtimes they can run on. That makes sense as it may be one to many (e.g. a .NET Core 2.1 agent may run on the 2.1.0/2.1.1/2.1.2 runtime, and could potentially be forced onto a specific version). Or alternatively, the exact runtime available may not be known until runtime (e.g. a CLR v4 agent can only run on the single version of the v4 CLR which is installed on a machine, so may run on netfx4.5 on one machine, and 4.8 on another)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants