Repository navigation
Cannot use "." characters in resource names #1399
Description
With a AppHost:
var apiservice = builder.AddProject<Projects.name_ApiService>("api.service");
builder.AddProject<Projects.name_Web>("web.frontend")
.WithReference(apiservice);You get a manifest that looks like:
"web.frontend": {
"type": "project.v0",
"path": "../name.Web/name.Web.csproj",
"env": {
"OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
"OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
"services__api.service__0": "{api.service.bindings.http.url}",
"services__api.service__1": "{api.service.bindings.https.url}"
},Which fails infra generation since the dot character in the binding api.service.bindings.http.url is not escaped:
If you run azd up, you get an error that looks like:
ERROR: generating infra/ folder: unknown resource referenced in binding expression: api
Activity
DamianEdwards commentedon Dec 15, 2023
I'm open to introducing restrictions on resource identifiers as long as we author an analyzer for it at the same time, so that the format validity can be seen directly in the editor as an error (and at build time too).
Based on some offline discussions, a suggested set of restrictions to start with might be:
mitchdenny commentedon Jan 11, 2024
Should we allow trailing hyphen ... no.
Should we allow consecutive hypens ... no.
Should we allow hyphens at all ... in my opinion .. no. The reason is that some resource types in cloud providers don't allow them.
We should consider forcing them all the lower case as well (also a constraint in some cloud providers).
DamianEdwards commentedon Jan 11, 2024
I think that's too restrictive of a baseline principle. Aspire doesn't itself map to any online cloud provider by itself and we shouldn't restrict resources to the union-set of all possible providers or even major providers. I think allowing a single separator char like hyphen in our resource names is required. If a given cloud platform doesn't support it for a given resource type, then the deployment tech should handle that translation.
bradygaster commentedon Jan 13, 2024
Storage account names don't allow capital letters. Sorry to pile on!
mitchdenny commentedon Jan 17, 2024
James Newton-King (@JamesNK)
JamesNK commentedon Jan 17, 2024
tldr; I like the rules that Damian Edwards (@DamianEdwards) proposed. I think the important part of this is sanitizing and reporting problematic names where required, e.g. convent name to lower case for an Azure storage account.
How often will resource names be used as an identifier in code gen C#? Hyphen isn't allowed in C# identifiers so a resource name can't be used to code gen a
my-cool-resourceproperty for example.I think the solution in this case is to convert hyphen to underscore in generated C# identifiers, e.g.
my-cool-resource->Resources.my_cool_resource.If names are case-insensitive, then it doesn't matter if capitals are allowed or not. If the resource name needs to be used as a storage account name, then it can safely be converted to lowercase, e.g.
MyCoolResource->mycoolresource.If a cloud provider doesn't support hyphens, then they could be removed when generating names for that cloud provider. For example,
my-cool-resourceis converted tomy_cool_resource(if underscores are allow) ormycoolresourceif only alpha characters are allowed.There could be conflicts between resources if there is
my-cool-resourceandmycoolresourcebecause they resolve to the same name, but we can prompt with an error if that rare situation occurs.JamesNK commentedon Jan 18, 2024
What about other names in the model? For example, endpoints can have a name. Should they have the same restrictions?
mitchdenny commentedon Jan 18, 2024
This is a good question. I think we should sanitise this input as well. Same restrictions.
JamesNK commentedon Jan 18, 2024
What else has a name?