.Net Core 2.0's NetStandard.Library targets-file breaks xbuild

[haf]

General

When .Net Core 2.0 was released, it seems to include a non-xbuild compatible .Targets file.

We've been debugging this issue here fsprojects/Paket#2616 – and it's indeed the targets-file of .Net Core that is the problem.

Could you please fix your package an unbreak me?

[karelz]

@weshaggard @ericstj can you comment please?

[ericstj]

I took a look at the referenced issue. It looks to me like a problem in mono's MSBuild project evaluation : fsprojects/Paket#2616 (comment).

Something about the syntax we use in our targets file is causing mono to null ref. None of our code is running here nor are we using invalid syntax, I suspect it's just a bug in xbuild. /cc @akoeplinger

If I had to guess, it seems that xbuild is trying to evaluate metadata when the condition on the item is false and the item is empty. That's just a wild guess though.

[akoeplinger]

xbuild is deprecated in Mono now that we have msbuild (and we show a message when using xbuild about that). I'd encourage everyone to switch over to msbuild :)

[haf]

Ping, this needs fixing.

[ericstj]

@haf we might be able to workaround it if someone could actually point out what the problem is. As I've already mentioned this isn't a bug in our targets but a bug in XBuild and @akoeplinger has mentioned not to use xbuild...

One thing you could try is the following:
Locate NETStandard.Library.targets inside the package.

Modify this line:
https://github.com/dotnet/standard/blob/d2b6c46ce1fa1d7d76a7f8f34b96da1d1053583e/netstandard/pkg/targets/NETStandard.Library.targets#L6

From

<ItemGroup>

To

<ItemGroup Condition="'$(_NetStandardLibraryRefPath)' != '' OR '$(_NetStandardLibraryLibPath)' != ''">

Let me know if that works-around the issue. If it does I might even have a workaround that doesn't require a package update.

[haf]

@ericstj I followed your heavy-handed, non-community discussed, deprecation and moved away from xbuild and onto the unproven and for F#-untested v5.2 of Mono, but the problem is still there, as described fsharp/fsharp-compiler-docs#795

So no, it's not xbuild that's at fault.

I'll try changing that line, be right back with how it goes.

[haf]

Unfortunately that didn't make a difference. Here's the output from ionide.

Object reference not set to an instance of an object\n  at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool+FSharpProjectFileInfo..ctor (System.String fsprojFileName, Microsoft.FSharp.Core.FSharpOption`1[T] properties, Microsoft.FSharp.Core.FSharpOption`1[T] enableLogging) [0x00129] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions@387 (System.Boolean enableLogging, Microsoft.FSharp.Collections.FSharpList`1[T] properties, System.String file) [0x0000f] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool+referencedProjectOptions@390.GenerateNext (System.Collections.Generic.IEnumerable`1[System.Tuple`2[System.String,Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectOptions]]& next) [0x00086] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1[T].MoveNextImpl () [0x00018] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1[T].System-Collections-IEnumerator-MoveNext () [0x00001] in <599f46db06d737baa7450383db469f59>:0 \n  at System.Collections.Generic.List`1[T]..ctor (System.Collections.Generic.IEnumerable`1[T] collection) [0x00077] in <c9f8153c41de4f8cbafd0e32f9bf6b28>:0 \n  at Microsoft.FSharp.Collections.SeqModule.ToArray[T] (System.Collections.Generic.IEnumerable`1[T] source) [0x0006a] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions@387 (System.Boolean enableLogging, Microsoft.FSharp.Collections.FSharpList`1[T] properties, System.String file) [0x00031] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.getOptions (System.String file, System.Boolean enableLogging, Microsoft.FSharp.Collections.FSharpList`1[T] properties) [0x00005] in <599f46db06d737baa7450383db469f59>:0 \n  at Microsoft.FSharp.Compiler.SourceCodeServices.ProjectCrackerTool.ProjectCrackerTool.crackOpen (System.String[] argv) [0x000cc] in <599f46db06d737baa7450383db469f59>:0 "},"OutputType":"exe","Info":{"SdkType":"verbose","Data":{}},"AdditionalInfo":{}}

[haf]

Ping

[ericstj]

I followed your heavy-handed, non-community discussed, deprecation and moved away from xbuild and onto the unproven and for F#-untested v5.2 of Mono

I'm not the one telling you this, you'll need to take that up with @akoeplinger and in the appropriate repo (presumably mono).

I'm sorry you're hitting this issue and feeling frustrated, I do want to help do what we can to improve this.

Now you appear to be hitting some different NullReference in Microsoft.FSharp.Compiler, but I suspect the same root cause (perhaps we're missing an inner stack). I'll try the repro steps you put into the FSharp compiler issue once I have some time later today.

In the meantime if you feel like doing more remote trial and error, you try removing the contents of those targets entirely we can see if I the problem goes away, then do some incremental additions to see what causes the parser to blow up. Ultimately those targets do nothing in a net461 project, they are only used to provide references in a netstandard2 project only.

[ericstj]

Ok, in the office. I have a repro. Working on the theory that XBuild + these targets was the only thing required I took a file>new project, net461 console app and installed the netstandard.library 2.0 package in it. That was enough to make xbuild null-ref. I'll debug it and get back to you.

[ericstj]

Ok, for me it was enough to simply make the change I mentioned above.

Through trial and error I found the XBuild is null-ref'ing when processing this
https://github.com/dotnet/standard/blob/d2b6c46ce1fa1d7d76a7f8f34b96da1d1053583e/netstandard/pkg/targets/NETStandard.Library.targets#L12 and https://github.com/dotnet/standard/blob/d2b6c46ce1fa1d7d76a7f8f34b96da1d1053583e/netstandard/pkg/targets/NETStandard.Library.targets#L18

It should even be processing those since the _NetStandardLibraryLibPath and _NetStandardLibraryRefPath should not be set for desktop projects and those items will be empty. For my repro it was enough to duplicate the conditions on the root ItemGroup.

So the whole file looks like:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <NETStandardLibraryPackageVersion>2.0.0</NETStandardLibraryPackageVersion>
  </PropertyGroup>

  <ItemGroup Condition="'$(_NetStandardLibraryRefPath)' != '' OR '$(_NetStandardLibraryLibPath)' != ''">
    <Reference Condition="'$(_NetStandardLibraryRefPath)' != ''" Include="$(_NetStandardLibraryRefPath)*.dll">
      <!-- Private = false to make these reference only -->
      <Private>false</Private>
      <!-- hide these from Assemblies view in Solution Explorer, they will be shown under packages -->
      <Visible>false</Visible>
      <Facade Condition="'%(FileName)' != 'netstandard'">true</Facade>
      <NuGetPackageId>NETStandard.Library</NuGetPackageId>
      <NuGetPackageVersion>$(NETStandardLibraryPackageVersion)</NuGetPackageVersion>
    </Reference>
    <ReferenceCopyLocalPaths Condition="'$(_NetStandardLibraryLibPath)' != ''" Include="$(_NetStandardLibraryLibPath)*.dll">
      <Private>false</Private>
      <Facade Condition="'%(FileName)' != 'netstandard'">true</Facade>
      <NuGetPackageId>NETStandard.Library</NuGetPackageId>
      <NuGetPackageVersion>$(NETStandardLibraryPackageVersion)</NuGetPackageVersion>
    </ReferenceCopyLocalPaths>
  </ItemGroup>
</Project>

After doing this, XBuild will successfully parse the targets and load and build the project.

Now I also tried using the latest mono and can confirm that this does not repro using msbuild.

If you'd like to examine this you can do the following:

git clone https://github.com/ericstj/scratch.git
cd scratch
git checkout 64b57914b6340164de63a4f69553655a1843ff92
cd net461ns2/ConsoleApp5
xbuild
# fails with Object reference not set to an instance of an object
git checkout d44a5070765830ba920c2c43d38a6c168bba1c25
xbuild
# succeeds

I then updated to mono 5.2.0.215.

git checkout 64b57914b6340164de63a4f69553655a1843ff92
xbuild
# still fails
msbuild
# succeeds
git checkout d44a5070765830ba920c2c43d38a6c168bba1c25
xbuild
# succeeds
msbuild
# succeeds

I made a PR to put the workaround in place.