No environnement name suggestion for Environnement.GetEnvironmentVariable()

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

When calling Environment.GetEnvironmentVariable the first parameter is the environnement name variable to be retrived.

It would be nice to have a list of predefined and well know environnement (here like ASPNETCORE_ENVIRONMENT or any Windows/Linux standard environnement variable) variable name as an IntelliSense suggestion

---

Original Comments

Feedback Bot on 7/19/2021, 08:07 PM:

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. We'll provide an update once the issue has been triaged by the product team.

Mika Dumont [MSFT] on 7/30/2021, 09:12 AM:

Thanks for taking the time to provide this feedback! In 16.10 Preview 2 we added a completion option that automatically inserts arguments when writing a method call. This feature is off by default so you will need to enable it in Tools > Options > Text Editor > C# > IntelliSense and select Tab twice to insert arguments (experimental). Start writing a method call and press tab twice (tab+tab).The method call should includes arguments based on the method’s default values. You can then use parameter info to cycle through the list of arguments that you would like inserted by pressing the up and down arrow keys. Let me know if this works for your scenario.

Why do we ask for more info?
We try to reproduce all issues reported with the information provided in the description and comments. When we can’t reproduce the issue, we ask you for more information so we can resolve the issue as quickly and efficiently as possible.
In our guidelines, you can get tips on how to provide clear and simple reproducible steps.

jeremie.leclercq on 8/2/2021, 00:48 AM:

Tried the mentionne option, how over is not adressing the initial suggestion.

Indeed the Environment.GetEnvironnementVariable has a single string parameter and is NOT optional (so no default value) :

I guess the proper way to adress is to create an enum at .Net level and to modify the method signature

=> Method Environment.GetFolderPath() is working this way

[mikadumont]

@CyrusNajmabadi did we recently add this?

[CyrusNajmabadi]

No, we did not. But a third party coudl by adding a completion provider for this.

[sharwell]

It seems like we could also add a string completion feature similar to how InternalsVisibleTo works for string literals.

[sharwell]

Design review conclusion: initially implement this by adding a completion provider for the string passed to Environment.GetEnvironmentVariable(), and populate the list with the names of the environment variables currently defined on the system. The list would not hard-select items to ensure any other item could be typed.

In the future, specific sub-proposals could be created to expand this list with support for well-defined buckets of items (e.g. well-known preprocessor directives in Azure Pipelines if the current project is known to use Azure Pipelines as a CI provider).

[NTaylorMullen]

Design Meeting Notes

[MaStr11]

Where should such a provider be integrated into

There are at least three places, where such a provider could be integrated into:

EmbeddedLanguageCompletionProvider

This approach is used by the DateAndTimeEmbeddedCompletionProvider which does this suggestion:

InternalsVisibleToCompletionProvider

This one completes [InternalsVisibleTo("$$")] by providing the assembly names of the solution. This one is based on LSPCompletionProvider.

ArgumentProvider

This isn't a completion provider and only seems to be able to suggest a single value. DefaultArgumentProvider is one of the derived types of this provider.

What other argument value suggestions should be considered

It seems reasonable to me to create a base class for argument values suggestions, because there are other .Net types in the BCL that would benefit from such a completion:

• System.Type.GetType("$$") suggest fully qualified type names
• new System.IO.DriveInfo("$$") suggest drive letters a to z
• Assembly.GetManifestResourceStream("$$") suggest embedded resource names
• new Uri("$$") PackUri completion for WPF.

There are a lot of parameters, with types beyond strings, where argument values can be suggested:

• System.Enum.GetValues($$) suggest all enums in scope: typeof(EnumInScope)
• Parameter of type CancelationToken suggest CancellationToken.None
• Parameter of type Task suggest Task.CompletedTask
• Parameter of type Task<T> suggest Task.FromResult()
• Parameter of type ImmutableArray<T> suggest ImmutableArray<T>.Empty
• Parameter of type IEnumerable<T> suggest Enumerable.Empty<T>()
• Parameter of type EventArgs suggest EventArgs.Empty
• Parameter of type StringComparer (or related interfaces), suggest StringComparer.Ordinal and the like
• For any parameter suggest new() if the parameter type has a parameterless constructor
• For number parameters, suggest Math.?? methods with the appropriate return type.

What should the provider look like

I like the idea of the ArgumentProvider to pass an ArgumentContext to an abstract method that all providers need to implement (ArgumentProvider can't be used as a base class here because it serves a different purpose).

I would create a base class (e.g. ArgumentValuesCompletionProviderBase) that would be triggered, whenever the cursor is in an argument expression position. This base class would have a abstract ProvideCompletionsAsync(ArgumentContext context) method. ArgumentContext could be derived from CompletionContext or could embed CompletionContext. It would also contain the IParameterSymbol and some other useful information about the argument context.

A derived provider like a abstract StringArgumentValuesCompletionProvider could be used as base class for Environment.GetEnvironmentVariable("$$"), System.Type.GetType("$$") and so on ([InternalsVisibleTo("$$")] is probably out of scope because attribute arguments are different from method arguments).

Another derived provider could be abstract TypeBasedArgumentValuesCompletionProviderBase, which could serve as a base class for all the parameter types with static factory methods or static default properties (CancellationToken.None, Task.FromResult(), etc.).

@sharwell and @CyrusNajmabadi What do you think about the proposal?

[sharwell]

The proposal seems like an interesting place to start. Note that static properties (e.g. CancellationToken.None and ImmutableArray<int>.Empty) are already implemented in completion (#52163). Arguments are just one of the locations where they work.

I'm not sure we need to be specific to arguments in the new provider. For example, setting a property value is very similar to passing an argument. Perhaps we call it a symbol value completion provider, and in the first round we only trigger it for arguments (associated with a parameter symbol). TypeBasedArgumentValuesCompletionProviderBase is even more general, and likely would trigger based on target-type completion and not based on the associated symbol at all.

[MaStr11]

I wasn't aware of #52163, but it solves 90% of the use cases I had in mind. It is also unclear, whether Roslyn should provide specialized suggestions for argument values. It is probably better to allow library authors to provide such suggestions, like they can provide diagnostics with analyzers (A nice use case are the matchers in FakeItEasy https://fakeiteasy.readthedocs.io/en/stable/argument-constraints/#other-matchers A custom provider could suggest A<string>.Ignore in a A.CallTo context).

String arguments are different, though. @CyrusNajmabadi created the EmbeddedLanguageCompletionProvider for such cases, and I'm not sure whether this one is extendable by library authors.

Are there any plans to open up Roslyn for library authors to extend completion in any of these places? If yes, suggestions for Environnement.GetEnvironmentVariable() should be based on that infrastructure. If there are no such plans, I would like to start with the Environnement.GetEnvironmentVariable() provider. @CyrusNajmabadi Such a provider, should be based on EmbeddedLanguageCompletionProvider, right?

[CyrusNajmabadi]

Closing out as this could be handled by an externla completoin provider. We are unlikely to add support for it ourselves.