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

dotnet build CLI issue with -v:n -bl in .NET 7 RC 1 builds #26965

Closed
jonathanpeppers opened this issue Aug 3, 2022 · 5 comments
Closed

dotnet build CLI issue with -v:n -bl in .NET 7 RC 1 builds #26965

jonathanpeppers opened this issue Aug 3, 2022 · 5 comments
Assignees

Comments

@jonathanpeppers
Copy link
Member

jonathanpeppers commented Aug 3, 2022

Describe the bug

Let me begin by saying this is weird. Not sure if it is a dotnet CLI issue or MSBuild.

This started happening here: dotnet/android#7217

I found if you do:

$ dotnet build -v:n -bl Xamarin.Android.sln -t:Restore || echo "Exit code: $?"
...
Determining projects to restore...
Exit code: 1

This seems to work fine if I remove the -v:n argument. Such as: dotnet/android@17bc865

If I try .NET 7 Preview 6 (just tried latest public build):

Time Elapsed 00:00:02.31

The exit code isn't printed because it was a success (was 0).

To Reproduce

Install .NET 7.0.100-rc.1.22402.10, and run -t:Restore -bl -v:n on a .sln file? I don't think there is anything special about our .sln. I also think it might happen for any target? Nothing special about Restore.

Exceptions (if any)

None? .binlog does not have errors either?

Further technical details

.NET SDK:
 Version:   7.0.100-rc.1.22402.10
 Commit:    3faa96e7bf

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  12.4
 OS Platform: Darwin
 RID:         osx.12-arm64
 Base Path:   /Users/jopepper/src/xamarin-android/bin/Debug/dotnet/sdk/7.0.100-rc.1.22402.10/

Host:
  Version:      7.0.0-rc.1.22381.5
  Architecture: arm64
  Commit:       508fef51e8

.NET SDKs installed:
  7.0.100-rc.1.22402.10 [/Users/jopepper/src/xamarin-android/bin/Debug/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.0-rc.1.22401.10 [/Users/jopepper/src/xamarin-android/bin/Debug/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.0-rc.1.22381.5 [/Users/jopepper/src/xamarin-android/bin/Debug/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]

Environment variables:
  Not set

global.json file:
  /Users/jopepper/src/xamarin-android/global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-CLI untriaged Request triage from a team member labels Aug 3, 2022
@baronfel
Copy link
Member

baronfel commented Aug 3, 2022

I just quickly tried this on Windows with 7.0.100-rc.1.22043.4 (the latest available to me from the installer repo table links) and couldn't reproduce the exit code error on my system. Not saying that you're not seeing a real problem, just that I couldn't quickly repro it.

@jonathanpeppers
Copy link
Member Author

jonathanpeppers commented Aug 3, 2022

Ok, if I prepend my command with DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER=true it also seems to fix this.

$ DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER=true dotnet build -v:n -bl Xamarin.Android.sln -t:Restore || echo "Exit code: $?"
...
Time Elapsed 00:00:01.92

@baronfel
Copy link
Member

baronfel commented Aug 3, 2022

@rokonec something for the team to check out

@rokonec
Copy link
Member

rokonec commented Aug 4, 2022

@jonathanpeppers That you for great bug report. Thanks to it we have found and fixed yet another elusive bug.
We plant to merge it into msbuild tomorrow and it will flow into SDK soon.

@rokonec rokonec added build and removed untriaged Request triage from a team member labels Aug 4, 2022
@rokonec
Copy link
Member

rokonec commented Aug 5, 2022

We believe it has been just fixed by related PR

@rokonec rokonec closed this as completed Aug 5, 2022
jonathanpeppers added a commit to dotnet/android that referenced this issue Aug 8, 2022
Changes: dotnet/installer@53587f9...8f63969
Changes: dotnet/linker@31a57b5...f09bacf
Changes: dotnet/runtime@aafa910...26a71c6
Changes: dotnet/emsdk@11a9acf...7b2cd1e

Updates:

* Microsoft.Dotnet.Sdk.Internal: from 7.0.100-rc.1.22374.1 to 7.0.100-rc.1.22407.1
* Microsoft.NET.ILLink.Tasks: from 7.0.100-1.22368.1 to 7.0.100-1.22377.1
* Microsoft.NETCore.App.Ref: from 7.0.0-rc.1.22367.4 to 7.0.0-rc.1.22403.8
* Microsoft.NET.Workload.Emscripten.Manifest-7.0.100: from 7.0.0-rc.1.22362.2 to 7.0.0-rc.1.22368.1

~~ Other Changes ~~

* Remove leading/trailing spaces from response file

Context: dotnet/sdk#26627

This is triggering a bug in the dotnet/sdk. We should probably just
leave these this way, as it is weird to have leading/trailing spaces.

* export `DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER=true` in both
`Makefile` and AzDO `.yaml`.

Context: dotnet/sdk#26965

We should be able to remove this in a future .NET SDK bump.

* Pass along BinaryFormatter warning to BinarySerializableConstraint

Context: https://github.com/dotnet/runtime/blob/197ae4c596553f7e6acb327ca2e31cc00c794c4d/src/libraries/System.Runtime.Serialization.Formatters/src/System/Runtime/Serialization/Formatters/Binary/BinaryFormatter.Core.cs#L11

Our build was failing with:

    src-ThirdParty/NUnitLite/Constraints/BinarySerializableConstraint.cs(57,17):
    error SYSLIB0011: 'BinaryFormatter.Serialize(Stream, object)' is obsolete: 'BinaryFormatter serialization is obsolete and should not be used. See https://aka.ms/binaryformatter for more information.'
    src-ThirdParty/NUnitLite/Constraints/BinarySerializableConstraint.cs(61,32):
    error SYSLIB0011: 'BinaryFormatter.Deserialize(Stream)' is obsolete: 'BinaryFormatter serialization is obsolete and should not be used. See https://aka.ms/binaryformatter for more information.'

I can add the same `[Obsolete]` messages on
`NUnit.Framework.Constraints.BinarySerializableConstraint` to solve
this error.

* [tests] add one `$(NoWarn)` for `SYSLIB0011`

Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
radical added a commit to radical/runtime that referenced this issue Sep 16, 2022
.. which causes it to crash. The issue is described in
dotnet/sdk#26965 besides other issues.

This can be removed once the sdk has a fix for this.
github-actions bot pushed a commit to dotnet/runtime that referenced this issue Sep 23, 2022
.. which causes it to crash. The issue is described in
dotnet/sdk#26965 besides other issues.

This can be removed once the sdk has a fix for this.
lewing pushed a commit to dotnet/runtime that referenced this issue Sep 24, 2022
* [wasm] Add workaround for msbuild issue

.. which causes it to crash. The issue is described in
dotnet/sdk#26965 besides other issues.

This can be removed once the sdk has a fix for this.

* fix build

* Add workaround for perf pipeline

* Add issue url

Co-authored-by: Ankit Jain <radical@gmail.com>
jonathanpeppers added a commit to dotnet/android that referenced this issue Sep 26, 2022
Context: dotnet/sdk#26965

We should be able to remove this in a future .NET SDK bump.

Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
jonathanpeppers added a commit to dotnet/android that referenced this issue Sep 26, 2022
Changes: dotnet/installer@60fdbb4...f9eb82e

Updates:

* Microsoft.Dotnet.Sdk.Internal: from 7.0.100-rc.2.22466.28 to 7.0.100-rc.2.22472.26

~~ Other Changes ~~

* export `DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER=true`

Context: dotnet/sdk#26965

We should be able to remove this in a future .NET SDK bump.

Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
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