[release/dev17.14] Tooling: Don't throw exceptions when generating code for file rooted outside of project #11868
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add ReadOnlySpan<T>.StartsWith(...) and EndWith methods that take a single T value. These were added for convenience in .NET 9. Note that these are polyfills that call into the .NET methods on .NET 9 or higher.
Add a couple of methods from System.IO.Path to PathUtilities: - IsPathFullyQualified - Doesn't exist on net472 or netstandard2.0 - IsPathRooted - The overload that takes a ReadOnlySpan<char> (used by IsPathFullyQualfied) doesn't exist on net472 or netstandard2.0
In a prior implementation, DefaultRazorProjectFIleSystem.NormalizeAndEnsureValidPath(...) called Path.Combine(...) which would return the second path if both were rooted. However, that behavior was not carried into the new implementation, resulting in cases where a path can be "double" rooted if it is an absolute path outside of the project root. This change uses PathUtilities.IsPathFullQualified(...) to restore the previous behavior.
If ITagHelperResolver.GetTagHelpersAsync(...) fails, it returns a default (not empty) ImmutableArray<TagHelperDescriptor>. If that happens, we would end up throwing an exception when trying to report success telemetry by accessing the "Length" property on the result. This change checks first to see if the result was actually a failure and reports failure instead, avoiding the exception.
Recently, a couple of calls to RazorProjectFileSystem.GetItem(...) were changed to pass a file path rather than a target path. This results in an exception being thrown in the DefaultRazorProjectFileSystem if the file path is rooted outside of the project root. Instead, it's important to pass the "target path", i.e. the "logical" path of a file within the project. This avoids breaking completely valid scenarios where a file is included in the Razor project from an outside path (such as a content file in a NuGet package).
chsienki
approved these changes
May 16, 2025
phil-allen-msft
approved these changes
May 16, 2025
phil-allen-msft
deleted the
dev/dustinca/backport-17.14-files-outside-project
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #11864 to release/dev17.14
Customer Impact
Regression
Testing
Risk
Medium. This affects how every Razor file is compiled in Visual Studio at design-time. However, this risk is mitigated by testing large solutions such as OrchardCore and MudBlazor.