dotnet/msbuild

Consider testing command lines to identify worker nodes

Open

#3,125 opened on Mar 23, 2018

View on GitHub
 (11 comments) (0 reactions) (0 assignees)C# (5,062 stars) (1,364 forks)batch import
.NET CoreArea: Performancebackloghelp wantedtriaged

Description

See https://github.com/Microsoft/msbuild/pull/3106#discussion_r176604238

Currently, in .NET Core, MSBuild will find all processes running in the dotnet host and attempt to connect to them as though they were MSBuilds. That shouldn't interfere with the other processes unless they have a named pipe named MSBuild{pid}, but it takes time during the node-connection process.

We should explore narrowing down the candidate processes beforehand. We could for example examine process command lines for /nodereuse:true and/or MSBuild.dll.

Questions that need to be answered:

  • How can this be done at all? AFAIK, there's no unified .NET API to get command lines of other processes on all platforms, so it might have to be platform-specific.
  • Is this faster than the current approach? Examining command lines will take some time.

Contributor guide

Tech stack
csharp
Domain
backendtoolingperformance
Issue type
performance
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Understanding of MSBuild node reuseFamiliarity with .NET process managementPlatform specific process API knowledge
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
Explore platform specific APIs to get command lines of other processes (e.g., /proc on Linux, WMI on Windows). Evaluate performance impact compared to current approach. Refer to PR #3106 discussion for context. Focus on narrowing candidate processes by checking for '/nodereuse:true' or 'MSBuild.dll' in command lines.