String interpolation does not work with some url - .net-5

Question

I don't know how to replicate the problem here... I let you see the problem I have:
I must build an url and I am using string interpolation:
var url = $"{_baseAddress}/api​/freightcategories/​{categoryCode}";
Here the result:
As you can see last part of the url is white.... and if I call that url via HttpClient I get a 404 error...
I replaced the line above with this line:
var url = string.Format("{0}/api​/freightcategories/{1}", _baseAddress, categoryCode);
I get this:
Now if I call the url via HttpClient everything works correctly.
Any idea?
Thank you

Answer 1

Bas Paap reply on url in interpolated string breaks syntax coloring:
When using an interpolated string that contains an url followed by an
interpolated value, the syntax highlighting thinks the interpolated
value is part of the url and formats it as a link, up to and including
the first parameter.
I guess the url is analyzed this way: When an http or https sequence is encountered at the beginning of a string, the process of building the url starts, and values are appended to url until there is something unknown, like an interpolated value.
According to your case, _baseAddress might be interpolated first, which results in url having the following value: https://yoururl.whatever/api/freightcategories/​, which is a valid url and it is formatted properly, and I guess here the formatting stops because the next value is an interpolated one, which is unknown at the moment (_baseAddress value is know, but categoryCode not yet), so it stops the formatting and when categoryCode is appended, is simply does not care about formatting the url further. (This is how I think it works and it makes sense).
Here is a quick solution to build an url using string interpolation:
var url = "h" + $"{_baseAddress.Substring(1)}/api​/freightcategories/​{categoryCode}";
When h will meet ttps://yoururl.whatever/api...., the https is encountered at the beginning and the formatting starts. _baseAddress and categoryCode values are already a part of second string.
It is their issue and, as far as I know, Microsoft didn't solve it yet.
Also, you can try to specify an Uri instance rather that a string when sending a request, something like
var uri = new Uri($"{_baseAddress}/api​/freightcategories/​{categoryCode}");
client.GetAsync(uri);