[release/10.0] Add a flag to hostfxr_resolve_sdk2_flags_t to silence error messages

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.

[github-actions]

Backport of #119729 to release/10.0

See dotnet/sdk#50632 for context.

hostfxr_resolve_sdk2 will print error messages to stderr by default. We can add a flag to the enum to allow for silencing these errors when we want to try to resolve an sdk, but a failure to resolve shouldn't be surfaced to the console.

Alternatives:

• Add a callback parameter for error messages the way we do for returning result paths. This could have a default to print to stderr and still be reasonable to backport.
• Add a new boolean parameter to silence warnings. I think flags make more sense, especially since there's already a flags parameter.
• Add a new API that only gets global.json information.
• Don't use this API anywhere in the CLI that we don't want to print resolution failures.

Customer Impact

• Customer reported
• Found internally

[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]

Regression

• Yes
• No

Testing

Unit tests were added to validate setting the flag does not iteract with other flags and that it does silence the stderr output.

Risk

Low. This adds a new flag to an existing API and should have no observable behavior on existing code. The main risk is that we come to regret the new public flag on the host API and have trouble deprecating it.

[agocke]

Let’s hold. I’m rethinking whether we should just revert

[agocke]

Actually, this has been commented out in SDK already -- I'll just close this for now. We can come back to it when Elinor + Aaron are back.