Hi. When using dotnet, we have a bunch of built-in...
# dotnet
f
Hi. When using dotnet, we have a bunch of built-in ways to manage configuration settings and secrets. What are the benefits to using Pulumi.<stack>.yml files instead? We now have entries in the yml files that are loaded by the code in the stack, only to be supplied as environment variables to a container app in Azure. Which might be okayish except the naming conventions are different. Pulumi's support for hierarchical content in yml has a limitation that means there's no obvious clean way to map it to the same settings values in the target application. Could I "just" use the idiomatic dotnet config rather than the Pulumi one without losing anything important?
f
ESC starts making sense here imo - you gain environment/"config set" composability, more control over hierarchical projections, easy env var support, and more... the major thing missing here is no .NET support for the ESC SDK and I don't believe there's a lot of idiomatic constructs e.g. a custom
ConfigurationProvider
in
pulumi-dotnet