Skip to content
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

ConfiguredProject-level service for determining whether a project is implicitly active #3060

Merged
merged 21 commits into from
Dec 20, 2017

Conversation

davkean
Copy link
Member

@davkean davkean commented Dec 18, 2017

Added a new ConfiguredProject-level service that allows services that live within that scope to "await" on being active:

await service.IsImplicitlyActiveTask;   // Blocked until the configuration becomes active

The current API shape matches that needed by ConfiguredProjectReadyToBuild. It will be extended to support "startup and shutdown" scenarios needed by the language service.

  • Tests
  • Events that enable startup and shutdown scenarios (Will do in a future check-in)
  • We need a better name than "active" to avoid confusion with "solution active".

@davkean davkean changed the title [WIP] ConfiguredProject-level service for determining whether a project is active ConfiguredProject-level service for determining whether a project is implicitly active Dec 19, 2017
@davkean
Copy link
Member Author

davkean commented Dec 19, 2017

tag @dotnet/project-system ready for review.

namespace Microsoft.VisualStudio.ProjectSystem
{
/// <summary>
/// Provides properties and events to track the implicit activation of an <see cref="ConfiguredProject"/>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: an ConfiguredProject.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

/// </summary>
internal static class CancellationTokenExtensions
{
#pragma warning disable CA1068 // CancellationToken parameters must come last
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider filing a bug to not fire this if the CancellationToken is a this parameter to an extension method.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private void OnImplicitlyDeactivated()
{
_isImplicitlyActiveSource = new TaskCompletionSource<object>();
Thread.MemoryBarrier();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you comment why this is required?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

{
EnsureInitialized(true);

_version++;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this going to be called from multiple threads?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is test code.

Copy link
Contributor

@jmarolf jmarolf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@davkean davkean merged commit 39455a4 into dotnet:master Dec 20, 2017
@davkean davkean deleted the ActiveConfiguredProject branch December 20, 2017 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants