-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Uri.TryCreate returns different results on Windows and Linux #76816
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDescriptionIt seems that the following call returns different results on Windows (current .Net 6 SDK on Windows 11 Desktop, latest Visual Studio) and Linux (Github Action with current .Net 6 SDK, ubuntu-latest, dotnet-version 6.0.x)!
No time for deeper investigations at this moment, but I hope that helps.... BR Reproduction StepsUri.TryCreate("/vendor.test.js",Urikind.Absolute, out var result) Expected behaviorwhatever it comes out: ist should be the same on Windows and Linux Actual behaviorDifferent results between Windows and Linux Regression?No response Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
This is by design. For better or worse, Uri supports parsing file paths, and on Linux "/vendor.test.js" is a valid absolute file path. |
Unexpected but acceptable Feel free to close the issue |
For reference, once #59099 (comment) is implemented, you should be able to avoid this by doing var options = new UriCreationOptions
{
UriKind = Urikind.Absolute,
AllowImplicitFilePaths = false
};
Uri.TryCreate("/vendor.test.js", options, out Uri uri) |
Description
It seems that the following call returns different results on Windows (current .Net 6 SDK on Windows 11 Desktop, latest Visual Studio) and Linux (Github Action with current .Net 6 SDK, ubuntu-latest, dotnet-version 6.0.x)!
Not testet with .Net 7 RCx!
On Windows the TryCreate function returns bool.false
On my CI Server (Github current Ubuntu) it returns true, and the outcoming Uri from type "file://"
No time for deeper investigations at this moment, but I hope that helps....
BR
Werner
Reproduction Steps
Expected behavior
whatever it comes out: ist should be the same on Windows and Linux
Actual behavior
Different results between Windows and Linux
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: