Seems like timing changes in the system have resulted in us recieving
generated C# for miscellaneous project files, so we're hitting this
assert more often now. Removing it doesn't seem to have any noticable
effects, we get the right C# content for the right projects soon after,
as the server loads information.
The work I did to make all of the public entry points on
`RazorProjectService` async did so by breaking up the operations in
multiple tasks. The operations themselves can't interleave because a
semaphore gates just one operation at a time. However, the updates to
the `ProjectSnapshotManager` made by each operation _can_ interleave
with other updates to the `ProjectSnapshotManager`.
This change ensures that all of the `RazorProjectService` operations are
atomic WRT to the `ProjectSnapshotManger` by running each operation
within a call to `ProjectSnapshotManager.UpdateAsync(...)`. In addition,
I've taken a suggestion from @ryzngard to change when the miscellaneous
files project is added to the `ProjectSnapshotManager` in the language
server. Before this change, the misc files project would be added by the
first call to `ISnapshotResolver.GetMiscellaneousProjectAsync(...)`.
Now, it's added during `SnapshotResolver` initialization. This allows
`GetMiscellaneousProjectAsync(...)` to become a synchronous method,
which has the positive effect allowing many of the downstream callers to
be synchronous as well. Ultimately, this allows all of the
`RazorProjectService` operations to be implemented synchronously, which
helps ensure that they are actually atomic.
* Reference the razor extension from the integration test project, so
that making a code change and running a test from Test Explorer actually
causes the new code to be tested
* Manually initialize the `ThrowingTraceListener` because it seems the
module initializer doesn't work with our wacky test infra (and I choose
not to try to understand the latter :P)
* Up the log level of the test logger, so the Text Explorer output
includes the full logs of the test run
Seems like we're hitting the error condition here, and so our
integration tests are firing telemetry for it. Would be better to debug
fail so we get a failed test and know what the scenario is.
Fixes#10295
`WorkspaceProjectStateChangeDetector` tests were taking an extra long
time to run because they didn't specify a faster delay `TimeSpan` to the
detector's `AsyncBatchingWorkQueue`.
The RazorProjectService APIs (e.g. AddDocumentAsync, UpdateProjectAsync, etc.) were chunked into multiple tasks and awaits. That means that other updates to the ProjectSnapshotManager could be interleaved with them. This change ensures that the operations are atomic (as far as the ProjectSnapshotManager is concerned) by running each within a call to ProjectSnapshotManager.UpdateAsync(...). Because of other changes to make CPU-bound async work synchronous the operations themselves can be made synchronous.
This change updates SnapshotResolver with an InitializeAsync method that is called when the LSP "initialized" endpoint is handled. When initialized, the SnapshotResolver adds the misc project to the ProjectSnapshotManager. Tests have been updated to call InitializeAsync whenever a SnapshotResolver is created.
* Unit tests for RazorProjectInfoEndpointPublisher
* Removing unnessary using directive
* Minor formatting/rename cleanup
* 'using' cleanup
* Use test accessors per CR suggestion
* Misc renames per CR suggestions
* Change test accessor to follow reference doc in Roslyn
Fixes#10294
This pull request removes Razor tooling's alternative logging systems
(`IErrorReporter` and `RazorLogger`) and unifies on
`Microsoft.CodeAnalysis.Razor.Logging.ILogger`. As part of this, I've
introduced a `RazorActivityLog` service that can be MEF imported in the
VS layer to write to the VS activity log. Also, I've add an
`ILoggerProvider` in the VS layer that automatically writes any warnings
and errors to the activity log.
It was tedious to get the actual argument right, so this checks for multiple forms and tries to correct them.
The following should be supported now:
eng\scripts\featureflag.ps1 -set -flag Razor.LSP.ForceRuntimeCodeGeneration -enable
eng\scripts\featureflag.ps1 -set -flag Razor\LSP\ForceRuntimeCodeGeneration -enable
eng\scripts\featureflag.ps1 -set -flag FeatureFlags.Razor.LSP.ForceRuntimeCodeGeneration -enable
eng\scripts\featureflag.ps1 -set -flag FeatureFlags\Razor\LSP\ForceRuntimeCodeGeneration -enable
This should make copying the value from code easier to figure out. We could also just assume feature flags start with FeatureFlags\LSP\Razor\<flagname> but that's not inherantly true, just happens to be for now.
This PR:
* Re-enables logging to test output for integration tests
* Increases the log level of all logging during integration tests
* Actually deploys Razor to the experimental hive so we're testing Razor
main on VS main
* Previously, without that change, we were testing using the integration
test source from main, against whatever bits were inserted in VS main.
This seemed odd to me, but if anyone thinks that is a desired test
scenario let me know. It does explain a couple of failures I remember
seeing ages ago, which was the reason I had backed out the logging in
the first place
* Output VS version info to the pipeline logs
This reverts commit d76f5c59d9, humorously
entitled "Check correct CancellationToken". Sorry @DustinCampbell 😁
What was happening was that when a project change was queued up, we
cancelled any previous work that was in play. This used to check the
disposal cancellation token, so we didn't try to release a semaphore
that was disposed. The change to use the passed in cancellation token
meant we never released the semaphore.
Dustin Campbell
David Wengier
Alex Gavrilov
Andrew Hall