Newtonsoft.Json file not found exception only when published with "produce single file" option

Viewed 552

To be absolutely clear, THIS IS NOT A DUPLICATE of millions of similar errors.

But this error is not new, there's something wrong with the package.

This is the most horrific bug I've ever encountered in my like 30 years experience.

First of all, my application using Newtonsoft.Json package works both with Debug and Release configurations.

Then I publish it with OneFile and ReadyToRun options.

When I try to run it I get: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'.

Now - the package is linked into my exe file. Like 15 other packages that works. That mechanism works even with Windows and Linux native libraries. The package I see in my dependencies is version 13.0.1.

This is the current version. My entire solution does not have a single string "13.0.0". The only references to Newtonsoft.Json package are to version "13.0.1".

But when launched from my single file build - Newtonsoft.Json decides to throw a FileNotFoundException.

I'm banging my head against the wall. WTF is going on? I had similar error long, long time ago, on .NET Framework 4.5. My new app is on .NET 5.0. It has no weird package version redirection stuff. It just uses nuget for packages, they are all defined in one place in my project file.

Is it a bug in Newtonsoft.Json, or somewhere else?

Obviously, I won't paste millions of lines of my production code here. The code is simple, in one place it does something like var x = new JObject() and it throws the exception.

The only way to reproduce it is to create a new C# project on .NET 5.0, add Newtonsoft.Json package reference, use any method from that package, then make 1 file publish of it and try to run it.

I'm not even sure if it will trigger the bug on other computers, because last time I've seen this error it happened only on one of my Windows servers, and not other machines.

1 Answers

If anyone stumbles upon that kind of issue, here's what solved the problem:

I manually deleted all bin and obj folders from my solution. Clean solution, and Batch build/Clean didn't help.

After manually removing all bin and obj folders and rebuilding the solution it works.

Where did the error sit? I have no idea. It seems like it's a bug in Visual Studio build system itself. If you find similar problem, maybe this would save you a few hours.

To make it extra clear - I changed NOTHING in code. There was no bug in my code. After just deleting all "temporary" folders from the solution it magically started to work and the FileNotFoundException magically disappeared.

BTW, I have my guess about what happened. I guess Newtonsoft works in a similar way as me, and probably as most of us releasing NuGet packages do: we complete those super cool new features, extended the API, of course they passed all of our tests. So we release version "x.0.0". Then suddenly some real life code immediately breaks! Then we find the new edge case to add to our tests and release version "x.0.1". We immediately deprecate package "x.0.0". Look at the Newtonsof.Json versions listed. See it? ;) Versions "x.0.0" live extremely short ;)

I still don't know how it breaks the VS / .NET build system, but it does. Whoever finds that out will become MVP instantly.

Now the shameless plug: https://github.com/HTD/Woof/tree/master/Tools/Nuke

A tool, part of the Woof Toolkit by yours truly. This nukes the packages cache and also removes all bin and obj directories below the directory the program was started. So - I keep all my sources in D:\Source directory. I keep my nuke.exe there. When I have a misbehaving package anywhere, I just run Nuke. Then the first build of any C# program takes ages, but the package problems are solved. Every time.

Of course it can be replaced with shell scripts, but since I speak C# better than any scripting language... It has no dependencies except .NET 6 you probably already have.

Don't be scared when you see over a hundred errors in WPF or Blazor applications. The .xaml and .razor files need rebuilding obj directories. Just wait for a while or build the project manually.

Related