Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Publishing a solution with 6.0 exe and 3.1 classlib to the same target path produces a corrupted output

See original GitHub issue


I created a .NET 6.0 C# project that referenced a .NET Core 3.1 project, published it as a self-contained application and tried to run it on a Linux server, but it threw the FileLoadException below. It turns out it’s not even necessary to reference the .NET 3.1 project - it’s enough for it to be included in the solution.

Reproduction Steps

Extract and in the repro directory (where repro.sln is) run:

dotnet publish --nologo -c Release --self-contained -r linux-x64 -o bin/pub-linux
cd bin/pub-linux

(I originally ran it on a remote server, but the problem still reproduces on the same machine where .NET SDK is installed.)

Expected behavior

The application runs and prints “It ran! (DATE/TIME)”

Actual behavior

System.IO.FileLoadException: Could not load file or assembly 'System.Runtime, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Runtime, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'


Don’t know.

Known Workarounds

It works when not building a self-contained application (but of course then the runtime has to be installed on the target server).


Happens on Ubuntu 18.04.6 and Linux Mint 20 (based on Ubuntu 20.04), both x64.

$ dotnet --info .NET SDK (reflecting any global.json): Version: 6.0.202 Commit: f8a55617d2

Runtime Environment: OS Name: ubuntu OS Version: 18.04 OS Platform: Linux RID: ubuntu.18.04-x64 Base Path: /usr/share/dotnet/sdk/6.0.202/

Host (useful for support): Version: 6.0.4 Commit: be98e88c76

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

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

Other information

dotnet publish appears to change which runtime DLLs are included depending on whether the .NET Core 3.1 project is referenced or not, so I’m guessing that the 3.1 version of System.Runtime.dll is getting mixed in somehow. Oddly, this only seems to happen when the .NET Core 3.1 project is outside the solution directory (as it is in the attached repro).

Issue Analytics

  • State:open
  • Created a year ago
  • Comments:11 (6 by maintainers)

github_iconTop GitHub Comments

vitek-karascommented, May 5, 2022

@loop-evgeny I moved the issue to the sdk repo (since this is a build-time problem) and updated the title to better match what’s going on.

As a workaround - run publish on a project directly, not on the solution (or directory in this case), that should make it work.

vitek-karascommented, May 5, 2022

There’s something really weird going on. The files are a combination of .NBT 6 (the app, native bits of the runtime like, .NET Core 3.1 (most of the System.* assemblies) and .NET Framework 4.* (some of the System.* assemblies, for example System.Runtime.dll).

It seems that running dotnet publish in a directory which has an .sln file will publish that solution. But if you also specify -o path all of the projects in the solution will be published to the same output directory. Combine that with the fact that dotnet publish --self-contained on a classlib project (the .NET 3.1 project is a classlib - it doesn’t have OutputType=exe) is effectively undefined behavior (I know… I’ve been complaining about this for a while), it produces a really weird output where some assemblies are 3.1 and some are 4.* - no idea how.

In short if the two projects are published in the wrong order (the console app first, then the 3.1 reference) it will produce basically garbage in the output folder.

If you run dotnet publish consoleproj.csproj then it will only build that one app and everything seems to work correctly. In my case I didn’t get a repro because first I didn’t try with -o path (didn’t seem important) and later when I did use it, I got lucky and it built the 3.1 first and then the consoleproj which overwrote everything with version 6.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Troubleshoot .NET Framework targeting errors
This article provides resolutions for MSBuild errors that might occur because of reference issues.
Read more >
Publish single executable not working for .NET 5 or .NET 6
Publishing the WPF application as a single executable works for .NET Core 3.1 (using ArcGIS Runtime 100.12). I used Visual Studio 2022 (17.0.5) ......
Read more >
The current .NET SDK does not support targeting . ...
NET SDK that supports .NET Core 2.1." I don't see ".net core 2.1" in my target framework. I don't have global.
Read more >
Java. This vulnerability - CVE - Search Results
A CWE-306: Missing Authentication for Critical Function vulnerability exists that could allow changes to administrative credentials, leading to potential remote ...
Read more >
This will generate a blank solution file with the same name as the current folder. ... WebFeb 19, 2020 · This is broken...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found