Fixes https://github.com/dotnet/razor/issues/11237
Needs https://github.com/dotnet/roslyn/pull/76002 and a version bump
Very simple one, though I was a little cheeky. There is basically no
code that could be shared, except for code that removes `__o` and
`k_BackingField` from the results, but those methods operate on VS LSP
types. Given cohosting largely uses Roslyn LSP types, and will be
exclusively FUSE, and FUSE doesn't have `__o`, I just skipped that bit.
Confirmed in VS that having cohosting and FUSE on makes for nice looking
results with no generated code artifacts.
Side note: I don't think anything will ever have `k_BackingField` in the
results, but there is zero test coverage so who knows! 😁
Fixes https://github.com/dotnet/razor/issues/6155
Me: I really like the cohosting code action tests, it must be really
easy to add a new code action now!
Me: Oh really? Well, try it and find out, I dare you!!
Me: <this PR>
(Also me: That wasn't as much fun as I expected. I have thoughts.)
This is an automatically generated pull request from release/dev17.13
into main.
Once all conflicts are resolved and all the tests pass, you are free to
merge the pull request. 🐯
## Troubleshooting conflicts
### Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its
path into the following searches:
- https://github.com/dotnet/razor/find/release/dev17.13
- https://github.com/dotnet/razor/find/main
Usually the most recent change to a file between the two branches is
considered to have introduced the conflicts, but sometimes it will be
necessary to look for the conflicting lines and check the blame in each
branch. Generally the author whose change introduced the conflicts
should pull down this PR, fix the conflicts locally, then push up a
commit resolving the conflicts.
### Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally
will work without conflicts. This is due to differences between the
merge algorithm used in local git versus the one used by GitHub.
``` bash
git fetch --all
git checkout -t upstream/merges/release/dev17.13-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.13
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.13-to-main --force
```
This is an automatically generated pull request from release/dev17.12
into release/dev17.13.
Once all conflicts are resolved and all the tests pass, you are free to
merge the pull request. 🐯
## Troubleshooting conflicts
### Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its
path into the following searches:
- https://github.com/dotnet/razor/find/release/dev17.12
- https://github.com/dotnet/razor/find/release/dev17.13
Usually the most recent change to a file between the two branches is
considered to have introduced the conflicts, but sometimes it will be
necessary to look for the conflicting lines and check the blame in each
branch. Generally the author whose change introduced the conflicts
should pull down this PR, fix the conflicts locally, then push up a
commit resolving the conflicts.
### Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally
will work without conflicts. This is due to differences between the
merge algorithm used in local git versus the one used by GitHub.
``` bash
git fetch --all
git checkout -t upstream/merges/release/dev17.12-to-release/dev17.13
git reset --hard upstream/release/dev17.13
git merge upstream/release/dev17.12
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.12-to-release/dev17.13 --force
```
Got sick of seeing messages about namespaces not matching folder names,
so thought I'd suppress it. Then Alex mentioned the formatting rule in
standup, and I thought tests deserve the same treatment.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2302211
This change adds a null check to
ProjectCapabilityResolver.ContainingProjectHasCapability(...) that was
incorrectly removed by 6cd5bd4ba6. Without
this null check, it is impossible to open a merge editor for a razor or
cshtml file. The merge editor has a few editors within it, and some of
them are not included in a project, so they have a null IVsHIerarchy.
This change adds a null check to ProjectCapabilityResolver.ContainingProjectHasCapability(...) that was incorrectly removed by 6cd5bd4ba6. Without this null check, it is impossible to open a merge editor for a razor or cshtml file. The merge editor has a few editors within it, and some of them are not included in a project, so they have a null IVsHIerarchy.
This is an automatically generated pull request from release/dev17.13
into main.
Once all conflicts are resolved and all the tests pass, you are free to
merge the pull request. 🐯
## Troubleshooting conflicts
### Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its
path into the following searches:
- https://github.com/dotnet/razor/find/release/dev17.13
- https://github.com/dotnet/razor/find/main
Usually the most recent change to a file between the two branches is
considered to have introduced the conflicts, but sometimes it will be
necessary to look for the conflicting lines and check the blame in each
branch. Generally the author whose change introduced the conflicts
should pull down this PR, fix the conflicts locally, then push up a
commit resolving the conflicts.
### Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally
will work without conflicts. This is due to differences between the
merge algorithm used in local git versus the one used by GitHub.
``` bash
git fetch --all
git checkout -t upstream/merges/release/dev17.13-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.13
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.13-to-main --force
```
* Update dependencies from https://github.com/dotnet/arcade build 20241122.2
Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk
From Version 9.0.0-beta.24562.13 -> To Version 9.0.0-beta.24572.2
* Failed to perform coherency update for one or more dependencies.
---------
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
The Razor compiler was carrying an old copy of
`TagHelperDescriptorJsonConverter`, though it was only used in
benchmarks. Since it doesn't make sense to have two JSON formats for tag
helpers, this change updates
Microsoft.AspNetCore.Razor.Serialization.JSON so that it can be
referenced by the compiler benchmarks and removes
`TagHelperDescriptorJsonConverter`. With this done, it will be easier to
slim down the `TagHelperDescriptor` API, which I'm planning to do to
speed tag helpers up a bit. (Although, that'll still require updates to
https://github.com/dotnet/sdk/tree/main/src/RazorSdk/Tool.)
I recommend reviewing commit-by-commit.
* Adding a setting to .editorconfig to enforce formatting
* Minor change to ```from``` formatting
* Removing extra spaces and supressions in flags per CR suggestion
I was musing the other day about ETW events possibly being useful in
tracking down the Speedometer regression I was looking in to, and then
along comes https://github.com/dotnet/razor/issues/11232 which is a
great excuse to add some ETW event infrastructure to our lives.
The idea here is that RPS/Speedometer tests can wait for Razor to be
"ready" by looking for this event, rather than `Thread.Sleep`ing.
Anecdotally on my machine, when loading OrchardCore, this event fires
once a couple of minutes after solution load, so seems like a reasonable
candidate.
Once this is in @WardenGnaw will try it out and if it's not good, we'll
pop some more events somewhere.
Will need to follow up with PR(s?) to add this event source name to the
list, but I need to work out where to do that first :)
VS Code has a specific LogOutputChannel which allows the user to easily change the logging level on an output window. To support that rzls also needs to allow dynamic logging level changes. This adds an endpoint and a level provider that changes the logging level based on an lsp message coming in.
This is is similar to the GenerateBaselines class. It updates the JSON files in the shared files folder. It is included in MS.ANC.Razor.ProjectEngineHost.Test rather than MS.ANC.Razor.Test.Common.Tooling for a couple of reason:
1. That's where most of the serialization tests live.
2. MS.ANC.Razor.Test.Common.Tooling is not a test project, so while the IDE will discover tests in that project, it won't run them.
Note that this change also updates the JSON because I actually ran the test. The JSON formatting is a bit different, which is where there are modifications.
David Wengier
dotnet-maestro[bot]
Andrew Hall
Jan Jones
dotnet bot
Phil Allen
Dustin Campbell
dotnet-maestro[bot]
Alex Gavrilov