Skip to content

ArgumentNullException in node issue with beta0014 #1458

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

Closed
li0nsar3c00l opened this issue Aug 21, 2018 · 20 comments
Closed

ArgumentNullException in node issue with beta0014 #1458

li0nsar3c00l opened this issue Aug 21, 2018 · 20 comments

Comments

@li0nsar3c00l
Copy link

Tested the new beta0014 version and got the following error message while building a .net standard library after adding the package. It compiles with the beta0012 version tho.

1>------ Neues Erstellen gestartet: Projekt: TestProject, Konfiguration: Debug Any CPU ------ 1>[NuGet Minimal]: Restoring packages for C:\Users\li0nsar3c00l\AppData\Local\Temp\0vdgm03o.fg3\dummy... 1>MSBUILD : error MSB4166: Der untergeordnete Knoten "2" wurde vorzeitig beendet. Vorgang zum Herunterfahren wird durchgeführt. Diagnoseinformationen finden Sie in den Dateien namens "MSBuild_*.failure.txt" unter "C:\Users\li0nsar3c00l\AppData\Local\Temp\". Dieser Speicherort kann geändert werden, indem Sie die Umgebungsvariable MSBUILDDEBUGPATH auf ein anderes Verzeichnis festlegen. ========== Alles neu erstellen: 0 erfolgreich, 1 fehlerhaft, 0 übersprungen ==========

Content of the referred file:

UNHANDLED EXCEPTIONS FROM PROCESS 16456:
=====================
22.08.2018 00:23:51
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: value
bei System.IO.BinaryWriter.Write(String value)
bei Microsoft.Build.Framework.LazyFormattedBuildEventArgs.WriteToStream(BinaryWriter writer)
bei Microsoft.Build.Framework.BuildMessageEventArgs.WriteToStream(BinaryWriter writer)
bei Microsoft.Build.Shared.LogMessagePacketBase.WriteToStream(INodePacketTranslator translator)
bei Microsoft.Build.Shared.LogMessagePacketBase.Translate(INodePacketTranslator translator)
bei Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue`1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
===================

Any ideas?

@ermshiperete
Copy link
Contributor

I'm getting the same problem:

MSBUILD : error MSB4166: Child node "3" exited prematurely. Shutting down. Diagnostic information may
be found in files in "C:\Users\user\AppData\Local\Temp\" and will be named MSBuild_*.failure.txt. This 
location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different 
directory.

@ermshiperete
Copy link
Contributor

This happens as soon as I build for more than one target framework, i.e. if I have a line like <TargetFrameworks>net40;net451</TargetFrameworks> in the .csproj file.

@JakeGinnivan
Copy link
Contributor

@asbjornu ideas?

@asbjornu
Copy link
Member

Hm, no. This makes no sense to me.

@dimio5
Copy link

dimio5 commented Aug 26, 2018

Are you compiling against .net SDK 2.1.401 while having 2.1.400 installed?
That was the issue for me. I upgraded .net core packages to 2.1.3 but did not realize I need to upgrade the SDK too.

@ermshiperete
Copy link
Contributor

ermshiperete commented Aug 27, 2018

I don't think .NET SDK is the problem. Same thing happens after I installed 2.1.401.

I created a minimal solution to repro: https://gist.github.com/ermshiperete/fd8baae02180f2156dc0c5bbf166b29d

Interestingly, it works when I build from the command line (in a VS2017 command line: msbuild /t:Restore;Build GitVersionIssue1458.sln).

The output of both a failed build from within VS2017, and a successful build from the command line can be seen in this gist: https://gist.github.com/ermshiperete/9b951afbc340686951610459e7c64608

@dazinator
Copy link
Member

dazinator commented Aug 28, 2018

Does this work if you add a global.json locking sdk version to 2.0.0
(Because PR to support builds with sdk > 2.0 has not been merged yet.)

@dazinator
Copy link
Member

dazinator commented Aug 28, 2018

Sorry, I have since spotted your PR #1459
I gave it a go. It fixes the multitargeting property so I have merged it. Sadly it didn't seem to resolve this issue though with the null argument exception.

@dazinator
Copy link
Member

dazinator commented Aug 29, 2018

I have repro this where dotnet build and msbuild succeed, but VS2017 fails. I am wondering if this has been caused as a result of the latest VS2017 update. I have raised an issue here: stazz/UtilPack#30

I'm going to see if I can repro this with VS 15.7

@dazinator
Copy link
Member

dazinator commented Aug 29, 2018

I uninstalled VS2017 15.8.2 and installed VS2017 15.7.6 from here: https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017

After that I was able to build fine from VS2017. So it seems to me that the VS Update to 15.8.X broke something.

Update: I did the same thing on aanother machine (downgraded from 15.8.1 to 15.7.6) and the issue still repros in 15.7.6.. So now I am confused.

@dazinator
Copy link
Member

Had confirmation over here: #1399 (comment) from someone successfully building from VS2017 15.8.1. So I am now wondering if this is just a VS2017 15.8.2 issue.

@ermshiperete
Copy link
Contributor

For me it's failing with VS2017 community 15.8.1.

Note that you'll have to look at the "Output" tab to see the failure - the "Error List" tab won't show anything in this case.

@ermshiperete
Copy link
Contributor

A global.json file doesn't help. Still getting the same error.

{
  "sdk": {
    "version": "2.0.0"
  }
}

@dazinator
Copy link
Member

dazinator commented Aug 29, 2018

@ermshiperete this is weird. As per #1399 (comment) this user is also using 15.8.1 and says everything is working fine. Im wondering what the difference is between their build environment and yours. Or perhaps they didnt check the output tab like you said.

@dazinator
Copy link
Member

@ermshiperete can you delete gitversion from your local nuget cache to force redownload. I can see that 'beta0015 package was actually built and published multiple times to the appveyor feed.

@ermshiperete
Copy link
Contributor

That was with beta14. But with beta15 I get the same result.

@dazinator
Copy link
Member

dazinator commented Aug 29, 2018

@ermshiperete I rolled back to 15.7.6 (on another machine since yesterday) and this time it still repros using the beta15 package.

However when I rolled the package version back from beta0015 to beta0014 (and killed msbuild.exe) - then unloaded / reloaded the project and rebuilt - it works.

Here is my csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net461</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitVersionTask" Version="4.0.0-beta0014">
      <!--<PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>-->
    </PackageReference>
  </ItemGroup>
</Project>

I then upgraded VS to 15.8.2 and built again. After the upgrade, both the beta14 and beta15 packages have the same error.

@dazinator
Copy link
Member

dazinator commented Aug 29, 2018

Did another downgrade to vs2017 15.7.6. Now, all of the packages are working fine (beta14, beta15, and my netstandard PR one) and I am unable to repro the issue at all.
I am not sure what is going on, but whilst things are working, I am going to be leaving my environment alone and not touching VS any further. I am still convinced it's a problem that VS 15.8.X introduced but that's just a gut feeling.

@dazinator
Copy link
Member

We had some help, see the linked msbuild issue - just need to try the workaround suggested there.

dazinator added a commit to dazinator/GitVersion that referenced this issue Sep 6, 2018
@dazinator
Copy link
Member

This should now be fixed in #1470

dazinator added a commit that referenced this issue Sep 6, 2018
fixes #1458 - msbuild null ref issue
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

6 participants