ResolveAssemblyReference throws InvalidOperationException on invalid PE files

[FiniteReality]

Issue Description

I have a project which produces native binaries (on linux, so ELF format) and when I use ProjectReference to indicate project dependencies, ResolveAssemblyReference tries to read the metadata of these files and throws InvalidOperationException because the dependencies don't use the PE format, or have metadata.

Steps to Reproduce

Reproducing this is pretty hard in my experience, since most ELF files make the PEReader throw a BadImageFormatException. I've opened a related issue in the .NET runtime because of this: dotnet/runtime#48419

The summary is, though:

1. Create a MSBuild project which produces a non-PE format file (e.g. by writing a large text file to $(IntermediateOutputPath)$(TargetName)$(TargetExt))
2. Try to reference that project from another using ProjectReference
3. Build the project in step 2

Expected Behavior

ResolveAssemblyReference skips the project because it doesn't have any metadata

Actual Behavior

ResolveAssemblyReference throws an InvalidOperationException from PEReader.GetMetadataBlock()

Analysis

Doing some digging, this appears to be caused by AssemblyInformation.CorePopulateMetadata not checking whether the created PEReader has any metadata. This appears to be checked everywhere else a PEReader is used:

• msbuild/src/Tasks/ManifestUtil/MetadataReader.cs

  Lines 35 to 42 in ca44138

  	_peReader = new PEReader(_assemblyStream, PEStreamOptions.LeaveOpen);
  	if (_peReader != null)
  	{
  	if (_peReader.HasMetadata)
  	{
  	_reader = _peReader.GetMetadataReader();
  	}
  	}

• msbuild/src/Shared/AssemblyNameExtension.cs

  Lines 214 to 220 in 6819f7a

  	bool hasMetadata = false;
  	try
  	{
  	// This can throw if the stream is too small, which means
  	// the assembly doesn't have metadata.
  	hasMetadata = peFile.HasMetadata;
  	}

Versions & Configurations

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.103
 Commit:    9effbc8ad5

Runtime Environment:
 OS Name:     debian
 OS Version:  
 OS Platform: Linux
 RID:         debian-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.103/

Host (useful for support):
  Version: 5.0.3
  Commit:  eae88cc11b

.NET SDKs installed:
  3.1.406 [/usr/share/dotnet/sdk]
  5.0.103 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
$ dotnet msbuild -version
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

16.8.3.61104

Attach a binlog

This binlog reproduces the issue, and I've been unable to reproduce it using smaller projects. I think this may be because smaller projects produce smaller binaries, which PEReader ends up rejecting. The source for the ClangLink and ClangCompile tasks can be found here.

[cdmihai]

I think the story with non-managed assemblies is that you have to add the ReferenceOutputAssembly="False" OutputItemType="Content" metadata to your ProjectReference item (docs). Can you please check whether this works for you?

[FiniteReality]

I think the story with non-managed assemblies is that you have to add the ReferenceOutputAssembly="False" OutputItemType="Content" metadata to your ProjectReference item (docs). Can you please check whether this works for you?

I'm currently building an MSBuild SDK to allow building of native projects (which is probably outside of the supported use case, which I'm fine with), so I'd rather not have to do that in each project - if there's an alternative place I can specify this (like GetTargetPath) then I might be able to build my own infrastructure for this. However, as it stands currently, I'm stuck relying on ResolveAssemblyReference working correctly, since it's an incredibly complex task which does a lot of things.

EDIT: For what it's worth, somehow the Visual C++ toolchain manages to let you use <ProjectReference Include="path/to/project.vcxproj"/> without ReferenceOutputAssembly and OutputItemType - I'm interested in replicating that behaviour for consumption. However, for legal reasons I obviously can't just look at how the Visual C++ toolchain manages it 😛