ASPIRE006: Why is underscore not allowed?

[lvde0]

I want to name my resources in snake case i.e. resource_name. However, ASPIRE006 prevents me from doing so:

Resource name 'resource_name' is invalid. Name must contain only ASCII letters, digits, and hyphens. (https://aka.ms/aspire/diagnostics/ASPIRE006)

What's the reason for that restriction? The docs are not really helpful.

I want to set some parameters via environment variables on the CI. For that I would need to set Parameters__resource-name which I personally find harder to read than just Parameters__Resource_Name

[davidfowl]

I assume you want to set parameter values that will be pick up via AZD? If yes then azd translates the names into yet another format for deployment https://learn.microsoft.com/en-us/dotnet/aspire/whats-new/dotnet-aspire-9.3#-consistent-predictable-parameter-naming

[davidfowl]

BUT when invoking aspire publish I want to pass additional parameters (to configure certificates etc.) as environment variables.

What do you mean by this? When you invoke aspire publish parameters do not have values.

[lvde0]

Aren't parameters backed by IConfiguration? So if I call aspire publish ... -- --Parameters:foobar=123 the parameter would be populated with that value from the command line and I could call ParameterResource.Value (or the GetValueAsync() equivalent) to get the value.

However, I just realized that the actual problem is the lack of ReferenceExpression support. It should never be required to retrieve the value of a parameter inside the AppHost. Ideally, all the builder extensions that take strings would also provide a ReferenceExpression overload. That way the parameter translation into environment variables would work and I can just provide them via the .env file.

I created a ticket for that: #10770

The original question still stands though: Are there any reasons to disallow "_" in resource names?

[davidfowl]

Aren't parameters backed by IConfiguration? So if I call aspire publish ... -- --Parameters:foobar=123 the parameter would be populated with that value from the command line and I could call ParameterResource.Value (or the GetValueAsync() equivalent) to get the value.

In publish mode parameters do not have a value.

I created a ticket for that: #10770

👍🏾

The original question still stands though: Are there any reasons to disallow "_" in resource names?

Our resource name rules map to dns names originaly because they were also used by default for service discovery (other resource types).

[lvde0]

In publish mode parameters do not have a value.

Mhm? I can retrieve the value of my ParameterResource just fine when publishing (i.e. !builder.ExecutionContext.IsRunMode) and it returns whatever value is present in the IConfiguration.

Our resource name rules map to dns names originaly because they were also used by default for service discovery (other resource types).

I see. I am just wondering about compatibility with environment variables. Shell variables (for instance) are restricted to alphanumeric characters and underscores and they're often used to set env variables.

Our resource name rules map to dns names originaly [...]

Does this mean that it's no longer required?

[davidfowl]

Mhm? I can retrieve the value of my ParameterResource just fine when publishing (i.e. !builder.ExecutionContext.IsRunMode) and it returns whatever value is present in the IConfiguration.

It's the equivalent of burning a string value into the published output. You may as well hard code a string. The point of parameters during publish is to express a parameter in the underlying system being published. If you are going to azure, a parameter will become a bicep parameter, for compose it becomes an env expression etc. When you use .Value (which is now deprecated), you are basically using a string value.

I see. I am just wondering about compatibility with environment variables. Shell variables (for instance) are restricted to alphanumeric characters and underscores and they're often used to set env variables.

There's a layer of indirection so the parameter itself is the app model concept and something has to map it to another concept in the target deployment language. There, the naming rules can be different.

Does this mean that it's no longer required?

No, we still do this.