-
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. #479 #480
Comments
same issue |
So far, the only solution I've found is to roll back to version 2.0.0-rc.3. It works well on Linux. |
I think it's a .NET 6.0 breaking change due to the code relying on an undocumented bug in UriBuilder for unknown URI Schems. dotnet/runtime#61363 (comment)
I wonder if we explicitly use the file:// protocol if it will work correctly. |
@junalmeida Do you want to try submitting a PR to fix it if I'm right? |
my backend uses Core 3.1 and runs under Linux, and I have exactly the same issue when I run it locally under Windows, everything works well |
And then there are tests that effectively exercise this general code path concept, indirectly:
|
@jzabroski 2.0.0-rc.4 and later - doesn't work - So currently I'm staying on the outdated version because it works at the production |
I see that I added #407 which uses AppContext.BaseDirectory for unit tests. If you add the following and replace the DI reference for the interface, does it work? public class PassthroughAssemblyDirectoryFormatter : IAssemblyDirectoryFormatter
{
public string GetAssemblyDirectory(Assembly assembly)
{
return assembly.Location;
}
} |
@jzabroski I would love to have the necessary expertise on your project to issue a good PR to fix this, however I don't think I have it yet, i.e I don't know how are your practices on tests and stuff. I have one more thing to add: I'm currently NOT using DI, instead, I'm using the
On the other end, the I can confirm that |
@junalmeida I see. The reason the UseNetFrameworkLegacyFix is called that is because Assembly.CodeBase is undefined in a single file application and now throws an exception in .NET Core. See: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file/overview#api-incompatibility Technically, Assembly.CodeBase still works when you're not in a single file application scenario. However, it is brittle. I suppose that:
@SerhiyBalan Does that work for you? I still think we don't have an explanation for why you can't use UriBuilder - can you try a simple console app that calls the new UriBuilder constructor: public void Main()
{
var location = typeof(Program).Assembly.Location();
Console.WriteLine(location);
var uri = new UriBuilder(location);
} |
This comment was marked as abuse.
This comment was marked as abuse.
@jzabroski Thank you for helping! I'm on vacation and will return on Tuesday. I will try everything from here and let you know if anything helped me to resolve the issue with the latest version of RazorLight |
|
This comment was marked as abuse.
This comment was marked as abuse.
Getting back to the point, I just realized that
So maybe the best is to not use |
I can't set a standard of incompetence, because then that's what I'll get. People who waste my time by not following adult etiquette, like reading documentation and generally understanding their job, are an unfortunate part of participating in open source software.
Correct.
This is a warning - you are trolling this thread at this point. |
This comment was marked as abuse.
This comment was marked as abuse.
Code in use:
Error stack trace (Azure, Linux, Core 3.1) at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) at System.Uri..ctor(String uriString) at System.UriBuilder..ctor(String uri) at RazorLight.Compilation.DefaultAssemblyDirectoryFormatter.GetAssemblyDirectory(Assembly assembly) at RazorLight.Compilation.DefaultMetadataReferenceManager.b__12_2(Assembly p) at System.Linq.Enumerable.SelectArrayIterator The suggestion to use
If you have some suggestions, please go ahead |
@SerhiyBalan Can I get detailed info on your Linux environment, e.g., which linux distro and version and libc and glibc? Maybe best to open a new ticket. This is great - I should be able to figure out a better approach. |
Describe the bug
Facing this exception while testing with dotnet test on ubuntu-latest on Azure DevOps:
I still have no idea of the value that
DefaultAssemblyDirectoryFormatter
is passing to Uri from the Assembly, no idea which Assembly in this the loop.The project is not bundle into a single DLL. This is happening during test on ubuntu. I'm trying to debug to see what Assembly is causing the error, but anyway simply passing
Assembly.Location
over toUriBuilder
is known to cause problems. Don't we need a check?To Reproduce
Steps to reproduce the behavior:
Just run tests on a setup with Embedded Resource Project.
Expected behavior
Probably expect that you might get an assembly with no valid location, as according to dotnet/corert#5467, the location may or may not exist, or could even be null.
Information (please complete the following information):
Additional context
It is a good practice to discuss before simply closing an issue. Thanks for understanding.
RazorLight/src/RazorLight/Compilation/DefaultAssemblyDirectoryFormatter.cs
Lines 10 to 11 in aceda13
The text was updated successfully, but these errors were encountered: