-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
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. |
Ok, if I prepend my command with
|
@rokonec something for the team to check out |
@jonathanpeppers That you for great bug report. Thanks to it we have found and fixed yet another elusive bug. |
We believe it has been just fixed by related PR |
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>
.. 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.
.. 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.
* [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>
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>
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>
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:
This seems to work fine if I remove the
-v:n
argument. Such as: dotnet/android@17bc865If I try .NET 7 Preview 6 (just tried latest public build):
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 aboutRestore
.Exceptions (if any)
None?
.binlog
does not have errors either?Further technical details
The text was updated successfully, but these errors were encountered: