Unable to build using <TargetFrameworks> tag on .NET 7 RC1

[masonwheeler]

Describe the bug

Visual Studio Preview suddenly fails to build in all sorts of interesting ways on code that used to work perfectly well in .NET 6. Any project with a <TargetFrameworks> tag in its csproj rather than a <TargetFramework> tag is barfing everywhere.

To Reproduce

• Setup .NET 7 RC1 on the latest Visual Studio Preview, using the links found on this announcement.
• Create a new solution with two new projects, for .NET 7. Project 2 should have a dependency on project 1 and should use a type declared in project 1.
• Alter project 1's csproj to say <TargetFrameworks>net6.0;net7.0</TargetFrameworks> rather than net7.0`
• Try to rebuild the solution. Watch as everything goes wrong.

Expected behavior:
This was working fine in .NET 6. It should continue to work fine in .NET 7.

Observed behavior:
First, Visual Studio complains about TargetFrameworkMoniker and NuGetTargetFrameworkMoniker properties being missing from the project. Then you manually rebuild project 1 and it works, but when you try to rebuild project 2, it has trouble with the types declared in project 1. VS very helpfully suggests adding a reference to project 1, even though project 2 already has one. An option to do so even shows up in the relevant ALT-ENTER popup menu. Selecting this option does nothing.

How did such a massive regression in such a basic piece of functionality end up in an RC?!?

[masonwheeler]

@igdmitrov That's literally the very first point in my repro steps: I'm on Preview, downloaded from that exact link.

[marcpopMSFT]

@dsplaisted could this be related to any of your recent rid and tfm changes?

[masonwheeler]

This issue appears to be fixed in the new VS Preview that dropped today. Not sure what you guys did, but I can build again.

[masonwheeler]

...scratch that. I can build, but when I try to run I get a bizarre error I've never seen before:

System.BadImageFormatException: 'Could not load file or assembly 'MyProject.MyDependency, Version=0.5.7.0, Culture=neutral, PublicKeyToken=null'. Reference assemblies cannot be loaded for execution. (0x80131058)'

What in the world is going on with reference assemblies at runtime?

[dsplaisted]

What happens if you build and run from the command line using dotnet run?

What about if you build from the command line with msbuild /restore and then run the executable directly from the output directory? Do you still get the same runtime error?

Would you be able to share a binlog of a command-line build with msbuild /restore?

[masonwheeler]

@dsplaisted
dotnet run: same error occurs.

msbuild /restore: same error occurs.

msbuild /restore -bl: here you go.

This is on a completely valid codebase, entirely unmodified from code that works as expected in .NET 6, except to add net7.0 targets. Whatever strangeness is going on with reference assemblies, it did not come from my end.

[marcpopMSFT]

Can you clarify the exact error that you're seeing? I don't see any errors in the binlog you just shared.
<edit>
Looks like you are working now with a newer version of VS for the build but it's run that's failing. That explains why the binlog doesn't have any errors as it's a runtime issue. If you're saying that 17.4-preview2.1 fixed your build, that release switches.net 7 to be the default SDK in VS but it sounds like you'd already enabled it in prior previews.

[masonwheeler]

Looks like you are working now with a newer version of VS for the build but it's run that's failing. That explains why the binlog doesn't have any errors as it's a runtime issue.

That's correct... sort of. Something is apparently causing it to try to load reference assemblies as dependencies at load-time. Either that or I'm reading the error message wrong. Not sure if that's a runtime error or if it was built wrong and has a bad reference in there now.

Strangely, when I open the assembly in question in ILDASM and look at the manifest, it has references to System.Runtime and other system assemblies marked as .ver 6:0:0:0 rather than version 7. Not sure if that's relevant in any way, but it's definitely unexpected.

[dsplaisted]

It looks like you're overriding the OutputPath of the projects so that they all output to the same folder. Can you try removing that to see if you still see the same problem?

If that doesn't help, can you provide an updated binlog of a build after a clean? The one that you provided skipped over some things since they were already up-to-date.

[masonwheeler]

Can you try removing that to see if you still see the same problem?

Same problem.

can you provide an updated binlog of a build after a clean?

msbuild.zip

[dsplaisted]

@masonwheeler Based on the error message it looks like a reference assembly is being copied to the output instead of an implementation assembly, but looking at the binlog I didn't find that happening.

Which assembly is it complaining about in the BadImageFormatException message, and which project is that happening for?

[masonwheeler]

@dsplaisted When I try to run the project ProtocolSaveTest, I get:

This is one of my own projects, which makes me suspect that somewhere, some dependency-of-a-dependency is pulling in a reference assembly.

The project in question has two external dependencies:

  <ItemGroup>
    <PackageReference Include="Microsoft.Data.SqlClient" Version="4.1.0" />
    <PackageReference Include="Microsoft.SqlServer.Types" Version="14.0.1016.290" />
  </ItemGroup>

It sure would be nice if we had more informative error messages that would tell us where the problem is actually occurring, rather than just the root of the dependency tree that's failing to load, now wouldn't it?

[masonwheeler]

Just for the record, I just tried building this with RC2 and the new version of Visual Studio Preview. The error remains unchanged.

[dsplaisted]

I think the issue is this, from ProtocolSaveTest.csproj:

  <ItemGroup>
    <Reference Include="Pansynchro.Connectors.MSSQL">
      <HintPath>..\Pansynchro.Connections.MSSQL\obj\Debug\net6.0-windows\ref\Pansynchro.Connectors.MSSQL.dll</HintPath>
    </Reference>
  </ItemGroup>

That is a direct reference to the reference assembly, which is probably causing it to be copied to the output folder. I think you can just delete that, since you already have a project reference to that project.

[masonwheeler]

Wow, that's bizarre. Why does that even exist?

[dsplaisted]

Wow, that's bizarre. Why does that even exist?

No idea. If you've got it in a source code repo you could look at the history / blame information to try to figure it out.