A number of NuGet libraries are failing to add with "No compatible assemblies found in package XXX"

macsux

I've encountered multiple packages that fail to install into LINQPad 6 with error message "Warning: No compatible assemblies found in package XXX". Some example packages:
System.Threading.Channels
System.Threading.Tasks.Dataflow

They seem to work fine when added to LINQPad 5

JoeAlbahari

This is correct behavior.

With these packages, the applicable assemblies are also present as part of .NET Core, so LINQPad uses assemblies from the NuGet package only if they have a higher version number. If you're getting this message, it means that the .NET Core assemblies have "won", and nothing is required from the NuGet packages.

wazzamatazz

I think I've run into a situation where this behaviour is not working as intended. I'm referencing a DLL in LINQPad 6 that I have built locally that references the System.Text.Json package @ version 4.7.1, which has an assembly version of 4.0.1.1. When I add this package to my query, I get the "No compatible assemblies found" message, but when I try and run my query, I get a CS1705 error:

CS1705 Assembly 'MyAssembly' with identity 'MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' which has a higher version than referenced assembly 'System.Text.Json' with identity 'System.Text.Json, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

Looking at the package contents, I can see that there are lib folder entries for net461, netcoreapp3.0, and netstandard2.0, so I would be expecting LINQPad to referencing the netcoreapp3.0 assembly in the package with assembly version 4.0.1.1 instead of the one that it is finding with assembly version 4.0.1.0.

EDIT: as an aside, I was able to work around this by directly referencing System.Text.Json.dll in the .NET Core SDK 3.1.201 folder (i.e. C:\Program Files\dotnet\sdk\3.1.201, as this is the same version distributed in version 4.7.1 of the NuGet package).

JoeAlbahari

Can you press F4, click 'Advanced' and right-click the 'Copy all NuGet assemblies...' checkbox. You should see an assembly resolution log - can you paste this please. Can you also post the .csproj file for the library that you're trying to reference.

rmbrunet

Just referencing System.Net.Http.Json and trying to use one of the Post methods throws CS1705:

CS1705 Assembly 'System.Net.Http.Json' with identity 'System.Net.Http.Json, Version=3.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' uses 'System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' which has a higher version than referenced assembly 'System.Text.Json' with identity 'System.Text.Json, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

The code to reproduce:

async Task Main() {

HttpClient httpClient = new HttpClient {
    BaseAddress = new Uri("https://jsonplaceholder.typicode.com")
};

using var response = await httpClient.PostAsJsonAsync("posts", new Post {Id = 1});

}

public class Post {
public int Id { get; set; }

public int UserId { get; set; }

public string Title { get; set; }

public string Body { get; set; }

}

JoeAlbahari

Thanks for reporting. The short story is that this will be fixed in the next build.

The long story is that this is an obscure problem created by the following things occurring together:

1. Microsoft updating the framework runtime assemblies more often than the reference assemblies, resulting in reference assembly version numbers that are lower than the runtime assembly version numbers
2. The System.Text.Json NuGet package not containing a reference assembly (bug?), forcing System.Net.Http.Json to be compiled against a runtime assembly (a practice Microsoft themselves don't recommend)
3. The System.Text.Json NuGet package containing a lib assembly whose version sits between the Framework runtime assembly version and the Framework reference assembly version.

Because you can use System.Net.Http.Json without error in Visual Studio, MSBuild must include some kind of hack to make this scenario work. I will add a similar hack to LINQPad.

rmbrunet

Thanks Joe!,

Surprisingly, changing the PostAsJsonAsyc call to another call in the same package works without a problem

var posts = await httpClient.GetFromJsonAsync<IEnumerable>("posts");

JoeAlbahari

The fix has now been released in the latest beta:
https://www.linqpad.net/linqpad6.aspx#beta

Let me know how you get along.

rmbrunet

Hi Joe,

After installing the last beta the error is gone.

Thanks,

R.

JohnGoldsmith

Hi,

Might this be the same issue on LINQPad 5?

I'm hitting this on one machine (the other resolves and works ok), where both LINQPad versions are 5.43.0:

CS1705 Assembly 'dotNetRDF' with identity 
'dotNetRDF, Version=2.6.1.0, Culture=neutral, PublicKeyToken=6055ffe4c97cc780' uses 
'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' which has a higher version than referenced assembly 'Newtonsoft.Json' with identity 
'Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'

I've deleted all other nuget packages apart from the dotNetRDF one, but I'm assuming that the confilict is within LINQPad 5's nuget cache - am I understanding this correctly?

(Note - I do have LINQPad 6 (6.11.11) installed on both machines and the query runs correctly on both)

Thanks

John

JoeAlbahari

If you're getting this error on one machine but not another, it's likely that there's a difference in how you've configured LINQPad. Check the 'My Extensions' query - any reference in here are added to all queries. Also check the default references - and that nothing is present in the plug-ins folder (My Documents\LINQPad Plugins).

JohnGoldsmith

Ah thank you. My Plugins folder appears to have contained the older version. I believe it comes from LINQBridgeVS. The Plugins folder contained:

• Framework 4.6 (folder)
• BridgeVs.Shared.dll
• Newtonsoft.Json.dll
• SharpRaven.dll
• System.IO.Abstractions.dll

I removed the VS extension however the dll's above still remained, so deleting these manually fixes the problem.

Thanks very much for your help Joe.

Best regards

John