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

ctrl-c on dotnet build doesn't always stop build #8739

Closed
danpere opened this issue Sep 20, 2017 · 1 comment
Closed

ctrl-c on dotnet build doesn't always stop build #8739

danpere opened this issue Sep 20, 2017 · 1 comment
Milestone

Comments

@danpere
Copy link

danpere commented Sep 20, 2017

Steps to reproduce

  1. Run dotnet build.
  2. Wait for version information notice to appear:
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
  1. Hit ctrl+c.

Expected behavior

No further output.

Actual behavior

The entire build runs displaying the normal output for the build.

This sounds similar to issues #7261 and #8610. I'm creating a separate issue because those are about dotnet run, not dotnet build.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
@peterhuene
Copy link
Contributor

Hi @danpere,

This should now be fixed in 3.0 with dotnet/cli#10720 (it'll be a little while before the fix shows up in the SDK nightly, though).

The dotnet build command is now consistent in its SIGINT handling so that it will allow the child MSBuild process to handle the SIGINT and terminate before the dotnet build command exits gracefully, returning the same exit code that MSBuild returned.

As I believe this is resolved, I am closing this issue. Please reactivate it if you can reproduce the behavior with a recent 3.0 SDK build. Thanks!

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Backlog milestone Jan 31, 2020
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

No branches or pull requests

3 participants