-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.UriFormatException: Invalid URI: The hostname could not be parsed #481
Comments
According to the suggestion from the separate issue, I've tried to replace a formatter with custom one
It didn't help. I still receive the same error |
I also faced the same issue these days. My environment is Linux VM on Azure, and the application is launching inside a Docker container. |
This can be reproduced locally just by running in a web api that runs in a docker container running linux - standard ms asp.net 6 image. We had to roll back versions for now. |
I'm also facing the same issue. |
I'll add a direct unit test for this class. |
Ok, got it to reproduce :D It failed on netcoreapp3.1, net5.0, net6.0, so I think the issue is rather systemic with Linux, and not tied to a particular Linux OS or .NET Core version. https://github.com/toddams/RazorLight/runs/6516867018?check_suite_focus=true#step:9:472
@SerhiyBalan ...That doesn't make a lot of sense! How can it produce the same error when the stack trace isn't calling the same code path? It definitely has to fail at a different place. |
I think I had a typo in my proposed solution - it should be: public class PassthroughAssemblyDirectoryFormatter : IAssemblyDirectoryFormatter
{
public string GetAssemblyDirectory(Assembly assembly)
{
return Path.GetDirectoryName(assembly.Location);
}
} |
@SerhiyBalan I think we almost had the right fix last week. See my latest checkin in master branch (same as code above). I think the reason you had the same exception is because you modified the ServiceCollection after you built the service provider. The moment you build a service provider, you've taken a snapshot of the universe of types. I recommend reading Microsoft's dependency injection guidelines, in particular https://docs.microsoft.com/en-us/dotnet/core/extensions/dependency-injection-guidelines#recommendations |
@jzabroski Thank you John for keeping assisting! For some unknown reason, both PassthroughAssemblyDirectoryFormatters do not work for me. I've opened RazorLight sources (master branch), my Rider IDE doesn't show usages of a constructor with IAssemblyDirectoryFormatter My application never goes to that constructor, it ignores my customized formatter. A debugger stops in an original formatter implementation Well, on Monday I will try to deploy customized builds of RazorLight to the Azure environment and try to find some workarounds |
@jzabroski I've tried to deploy several builds - referencing original RazorLight source codes (actual version of master branch, comit Build 1: DefaultAssemblyDirectoryFormatter with UriBuilder it fails with "Invalid URI: The hostname could not be parsed." Build 2 (DefaultAssemblyDirectoryFormatter with Path.GetDirectoryName): DefaultAssemblyDirectoryFormatter returns "/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.23" After that it fails in DefaultMetadataReferenceManager with an exception
Inner exception: P.S., as a reminder, 2.0.0-rc.3 works perfectly :/ |
It appears that my change here broke some of this: #407 Ultimately, we need better docs and FAQ support for what this code path is trying to accomplish. There is no general way to solve this problem for any arbitrary .NET deployment, as it requires knowledge of how the assembly is transformed into a .dll I would still call this an undocumented regression and take ownership of it, though. It should have been documented. |
DefaultMetadataReferenceManager should probably allow all ctors to take the IAssemblyDirectoryFormatter |
Same issue here. Getting an error during rendering a view (that doesn't use URI just string and one property named Url). It happens on docker build on top of mcr.microsoft.com/dotnet/aspnet:3.1 at 05/31/2022 14:57:26 error: System.UriFormatException: Invalid URI: The hostname could not be parsed. |
I will fix this today |
Update - I had to do an emergency hotfix at my day job yesterday, so promise to fix this yesterday was broken. I have not forgotten about it. |
Any update on this one? We are experiencing the same issue, and are trying to get a fix to a client as soon as possible. |
I face the same issue with NET6.0 on a Linux Docker container. Any idea if/when this will be fixed, or if there's a workaround for it in the meanwhile? |
Related: #411 |
Anyone found a workaround to this issue ? |
Yes, use 2.0.0-rc.3, as mentioned in #481 (comment) |
…3 to avoid bug described by toddams/RazorLight#481
Just to add some extra context onto this, the reason 2.0.0-rc.3 is working perfectly for people even though in theory it contains this commit 71383e4 which changes from Using a script like this: #!/usr/bin/env bash
set -e
versions=( 2.0.0-rc.1 2.0.0-rc.2 2.0.0-rc.3 2.0.0-rc.4 2.0.0-rc.6 2.0.0 )
for ver in "${versions[@]}"
do
echo "${ver}"
curl -SsL -o "${ver}.nupkg" "https://www.nuget.org/api/v2/package/RazorLight/${ver}"
unzip -v "./${ver}.nupkg" | grep "RazorLight.dll"
done Outputs the following, note the same checksums for rc.2 and rc.3:
And downloading/extracting the rc.3 package and looking at the assembly in dotpeek: |
Rename to `IAssemblyPathFormatter` as it returns the path to the assembly, not its directory. Fixes toddams#481
I thought I delisted rc.3 |
@Xtansia Thanks for pointing out RazorLight rc.3 was still listed. I just delisted it. It might take an hour to circulate through nuget.org package cache, and longer for any nuget replicas. |
New 2.1.0 release with this change is now on nuget.org @SerhiyBalan Can you let me know how you make out |
@jzabroski Thank you very much Verified at the following platforms: Azure Web Service: .NET 6 + Unix Works like a charm! |
Thank @Xtansia not me. I just am the messenger of his good deeds. |
Describe the bug
RazorLight works perfectly on my laptop (Windows).
It also works perfectly at Azure Functions (Windows) (service functions to do various tasks)
However I have issues at Azure Application Service (Linux): (main application backend)
Invalid URI: The hostname could not be parsed.
Stack Trace:
To Reproduce
Create an account at Azure (perhaps it allows to do that using a free tier)
Create a new Application Service and select Linux as OS:
I use following source codes (cleaned from logging stuff and unnecessary methods)
Expected behavior
It shouldn't fail :)
It works well on 2.0.0-rc.3 and earlier. It doesn't work after that
Information (please complete the following information):
Production environment (gathered from Azure Kudu):
Development environment (gathered from Azure Kudu):
Additional context
For now, I have to use 2.0.0-rc.3 until this issue is resolved in the latest RazorLight package
I can test any internal builds at the Azure development environment - just let me know :)
The text was updated successfully, but these errors were encountered: