This is some code I had locally and decided it would be good to check
in. There should be no observable change. This essentially removes some
unneeded bits, hides internal state, tights assumptions, simplifies
code, and cleans up test infrastructure. The commit history should be
explanatory.
* Unpin Roslyn Versions
Now that we have the analyzer work done in VS, we should be able to unpin the versions of the roslyn compiler that we depend on in razor.
* Remove VersionOverrides
* Make base type a token rather than a string
* Track inherits source location and emit it when present
* Add simple inherits test for components
* Add razor page inherits test
DocumentSnapshot and ProjectSnapshot had several virtual methods intended to be overridden in test infrastructure. This change removes the override behavior in tests and seals the classes.
Noticed while working on my previous PR. There were a few methods in
RazorProjectService that were only used by tests, and also resulted in
some tests validating things that could never happen in the product
(like passing `null` for a project file path in an update). This PR
removes one unused method, moves one to a test accessor where it rightly
should be, and updates the tests that were calling `UpdateProjectAsync`
to instead call through `IRazorProjectServiceListener.UpdatedAsync`.
I don't love that these tests have to call through that interface, but I
didn't change the method to be implicitly implemented because I don't
think the name makes sense when written that way.
There are, or at least should be, no functionality changes in this PR.
Fixes https://github.com/dotnet/razor/issues/10970
Each commit in this PR essentially hardens the project system a little
bit more. Together they fix the publish issue, which is a particularly
difficult scenario, as it essentially removes and quickly re-adds a
project, but I think the changes are pretty good overall. No one commit
fixes the publish issue, and I wouldn't say there is no more work to do,
but forward progress is forward progress.
Each commit is isolated to a particular service and has a brief
description of what the change is and why, but I think it's perfectly
understood when looked at as a whole too. Review however you prefer :)
This change decouples the two TagHelperTooltipFactories from the Razor
language server and moves them to the Workspaces layer for use in
co-hosting. Ultimately, co-hosting will be able to do a better job
producing hover and completion item tooltips, but that can come later.
This is an automatically generated pull request from release/dev17.12
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.12
- 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.12-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.12
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.12-to-main --force
```
When all documents are removed from a project, if the imports file comes first, it will cause a recompile of all open razor files, even though they will themselves later on be removed.
This didn't used to cause any issues during publish, because the generated document would
be sent over, and later clobbered with a subsequent change. Now that documents are self-versioned, that subsequent change could be for a version number less than the removed document, and hence be thrown away. Plus it's wasted work.
Now that snapshots are self-versioned, if we don't keep our "previously published data" clean we'll end up re-publishing versions of documents that are new on the client side, but not new on the server.
When publishing, we see a project remove for obj/Debug, and move all files to the misc
project, then we'd see a new project for obj/Release, and add that. That add would then
cause us to go through all of the misc files, and add them to the first project that could
possibly have them - in this case, adding them right back to obj/Debug.
Generally speaking we shouldn't be guessing at anything with project info, but rather rely
on correct input from systems. ie, if they add a project, they presumably will then follow
up with telling us which documents are in it.
The things receiving project events on the server side were all batching their work together, so quick
remove-then-add sequences for documents would be merged together on the server side. Not doing that on
the client side too just made it much harder for things to ever be in sync.
This was previously using the hash code of the document snapshot, therefore publishing every request. This meant
we got publishes for old documents when they were superseded by newer ones.
Dustin Campbell
Fred Silberberg
Jan Jones
David Wengier
Chris Sienkiewicz
dotnet bot
Ankita Khera