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

Feature: Add extensibility to the DotnetCliCommand #2693

Open
dmitriyse opened this issue Jan 22, 2025 · 2 comments
Open

Feature: Add extensibility to the DotnetCliCommand #2693

dmitriyse opened this issue Jan 22, 2025 · 2 comments

Comments

@dmitriyse
Copy link

dmitriyse commented Jan 22, 2025

It would be beneficial if all methods of the DotnetCliCommand were virtual.

It's impossible to customize the build/restore behaviour of the CsProjCoreToolchain.

Motivation:
For large project, it's beneficial to use all CPU cores for compilation

The disabled parallel build:

/p:BuildInParallel=false /m:1

can be replaced with

--nodeReuse:false
@timcassell
Copy link
Collaborator

I imagine we could just branch off of the sdk version, using --nodeReuse:false for the sdks that support it, and using /p:BuildInParallel=false /m:1 for older sdks.

cc @adamsitnik Who added those arguments.

@adamsitnik
Copy link
Member

I have added this many years ago, but I was lucky enough to add a comment for future myself:

// we use these settings to make sure that MSBuild does the job and simply quits without spawning any long living processes
// we want to avoid "file in use" and "zombie processes" issues

If .NET 8+ SDK (I don't believe we should add any complexity for recognizing older, unsupported SDKs) does not start any long-living processes with --nodeReuse:false I am supportive of replacing /p:BuildInParallel=false /m:1 with this argument 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants