New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Npgsql 3.2.4 Could not resolve field token 0x0400052b #1633

Closed
j-hotlink opened this Issue Jul 4, 2017 · 14 comments

Comments

Projects
None yet
7 participants
@j-hotlink

j-hotlink commented Jul 4, 2017

This duplicates #1603 (which is closed), however unlike #1603 , referencing System.Threading.Tasks.Extensions.dll does not fix for me.

Npgsql version: 3.2.4.1
PostgreSQL version: 9.1
Operating system: Ubuntu 14.4

Attached is a minimal configuration to reproduce error using fsharpc (extract to folder and run make).

test.zip

Output reads:

...
fsharpc --simpleresolution --standalone --tailcalls+ --debug:full --target:exe src/App.fs --out:bin/debug/test.exe --reference:refs/sqlprovider/SQLProvider.1.1.4/lib/FSharp.Data.SqlProvider.dll --reference:refs/npgsql/System.Threading.Tasks.Extensions.4.3.0/lib/portable-net45+win8+wp8+wpa81/System.Threading.Tasks.Extensions.dll --reference:refs/npgsql/Npgsql.3.2.4.1/lib/net45/Npgsql.dll
F# Compiler for F# 4.1
Freely distributed under the Apache 2.0 Open Source License

/home/jon/organisation/hotlink/projects/hotlink/postgres-test/src/App.fs(3,12): error FS3033: The type rovider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Could not resolve field token 0x0400052b

/home/jon/organisation/hotlink/projects/hotlink/postgres-test/src/App.fs(3,12): error FS3033: The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Failure has occurred while loading a type.
make: *** [bin/debug/test.exe] Error 1

@tamizhvendan

This comment has been minimized.

Show comment
Hide comment
@tamizhvendan

tamizhvendan Aug 27, 2017

+1. I am also facing the same issue. As suggested in 1603, downgrading to NuGet version 3.1.10 solves this issue.

tamizhvendan commented Aug 27, 2017

+1. I am also facing the same issue. As suggested in 1603, downgrading to NuGet version 3.1.10 solves this issue.

@mikkeljohnsen

This comment has been minimized.

Show comment
Hide comment
@mikkeljohnsen

mikkeljohnsen Sep 7, 2017

I now has the same issue on Windows. And I have System.Threading.Tasks.Extensions.dll installed

mikkeljohnsen commented Sep 7, 2017

I now has the same issue on Windows. And I have System.Threading.Tasks.Extensions.dll installed

@j-hotlink

This comment has been minimized.

Show comment
Hide comment
@j-hotlink

j-hotlink Sep 11, 2017

Unfortunately downgrading to 3.1.10 does not fix for me, and nor does upgrading to 3.2.5

j-hotlink commented Sep 11, 2017

Unfortunately downgrading to 3.1.10 does not fix for me, and nor does upgrading to 3.2.5

@alex-mazzariol

This comment has been minimized.

Show comment
Hide comment
@alex-mazzariol

alex-mazzariol Sep 30, 2017

What's interesting is that just copying the "System.Threading.Tasks.Extensions.dll" file in the dll search path (i.e. directory of the EXE) it starts working. In my case, since the project using Npgsql was being referred by 2 dll "layers" before finally reaching the EXE, msbuild's broken dependency pruning was preventing the System.Threading.Tasks.Extensions.dll file from being copied in the EXE directory.

A package upgrade/downgrade may restore the DLL, based on the actual dependency graph of your applications.

I think the actual issue is oblique dependency on this package's features without a proper check by Npgsql for its availability, with a fallback if it can be made or a proper exception message if a fallback is not an option. At the same time, since other packages (i.e. EntityFramework) do not seem to suffer from the same problem (their DLL is brought along up to to the EXE project), maybe it can be worth checking the NuGet packaging settings: maybe it can be fixed in that place.

alex-mazzariol commented Sep 30, 2017

What's interesting is that just copying the "System.Threading.Tasks.Extensions.dll" file in the dll search path (i.e. directory of the EXE) it starts working. In my case, since the project using Npgsql was being referred by 2 dll "layers" before finally reaching the EXE, msbuild's broken dependency pruning was preventing the System.Threading.Tasks.Extensions.dll file from being copied in the EXE directory.

A package upgrade/downgrade may restore the DLL, based on the actual dependency graph of your applications.

I think the actual issue is oblique dependency on this package's features without a proper check by Npgsql for its availability, with a fallback if it can be made or a proper exception message if a fallback is not an option. At the same time, since other packages (i.e. EntityFramework) do not seem to suffer from the same problem (their DLL is brought along up to to the EXE project), maybe it can be worth checking the NuGet packaging settings: maybe it can be fixed in that place.

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Oct 3, 2017

Member

If someone can submit a simple repro (preferably in C# not F#) that demonstrates this issue on a clean machine, that would help me investigate what the issue is. As it is I don't have the necessary info to start investigating...

Member

roji commented Oct 3, 2017

If someone can submit a simple repro (preferably in C# not F#) that demonstrates this issue on a clean machine, that would help me investigate what the issue is. As it is I don't have the necessary info to start investigating...

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Oct 22, 2017

TLDR: I think this is not a problem of Npgsql. Try to update your SQLProvider 1.1.4 to 1.1.15. If it won't help, please open a bug to SQLProvider.

The thing here is that SQLProvider uses Npgsql via reflection on compile-time. This way it supports multiple versions of Npgsql (as type providers are compiler plugins, on some sense, compile-time is runtime for them). But .NET reflection also needs the dependency components (System.Threading.Tasks.Extensions.dll in Npgsql case) to be available, and by default, .NET has binding redirects but they are not affecting to reflection loading. So the dependency had to be exactly the same version than was the dependency in Npgsql.dll. Which may not be the case if NuGet or Paket has loaded the latest version.

The solution was to create a custom binding redirects via AssemblyResolve-events which solves the dependency conflicts. They are now present in the latest version of SQLProvider (e.g. 1.1.15). So you still need the System.Threading.Tasks.Extensions.dll to resolutionPath on compile-time but now it should be enough to copy it from your current packages.

Thorium commented Oct 22, 2017

TLDR: I think this is not a problem of Npgsql. Try to update your SQLProvider 1.1.4 to 1.1.15. If it won't help, please open a bug to SQLProvider.

The thing here is that SQLProvider uses Npgsql via reflection on compile-time. This way it supports multiple versions of Npgsql (as type providers are compiler plugins, on some sense, compile-time is runtime for them). But .NET reflection also needs the dependency components (System.Threading.Tasks.Extensions.dll in Npgsql case) to be available, and by default, .NET has binding redirects but they are not affecting to reflection loading. So the dependency had to be exactly the same version than was the dependency in Npgsql.dll. Which may not be the case if NuGet or Paket has loaded the latest version.

The solution was to create a custom binding redirects via AssemblyResolve-events which solves the dependency conflicts. They are now present in the latest version of SQLProvider (e.g. 1.1.15). So you still need the System.Threading.Tasks.Extensions.dll to resolutionPath on compile-time but now it should be enough to copy it from your current packages.

@anon17

This comment has been minimized.

Show comment
Hide comment
@anon17

anon17 Mar 7, 2018

@roji test project

Error:

$ mono testnpg.exe

Unhandled Exception:
System.BadImageFormatException: Could not resolve field token 0x0400052b
File name: 'Npgsql'
  at Npgsql.NpgsqlConnection.Open () <0x411f8d70 + 0x00033> in <filename unknown>:0 
  at testnpg.Program.Main (System.String[] args) <0x411bed50 + 0x000fd> in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.BadImageFormatException: Could not resolve field token 0x0400052b
File name: 'Npgsql'
  at Npgsql.NpgsqlConnection.Open () <0x411f8d70 + 0x00033> in <filename unknown>:0 
  at testnpg.Program.Main (System.String[] args) <0x411bed50 + 0x000fd> in <filename unknown>:0

anon17 commented Mar 7, 2018

@roji test project

Error:

$ mono testnpg.exe

Unhandled Exception:
System.BadImageFormatException: Could not resolve field token 0x0400052b
File name: 'Npgsql'
  at Npgsql.NpgsqlConnection.Open () <0x411f8d70 + 0x00033> in <filename unknown>:0 
  at testnpg.Program.Main (System.String[] args) <0x411bed50 + 0x000fd> in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.BadImageFormatException: Could not resolve field token 0x0400052b
File name: 'Npgsql'
  at Npgsql.NpgsqlConnection.Open () <0x411f8d70 + 0x00033> in <filename unknown>:0 
  at testnpg.Program.Main (System.String[] args) <0x411bed50 + 0x000fd> in <filename unknown>:0
@anon17

This comment has been minimized.

Show comment
Hide comment
@anon17

This comment has been minimized.

Show comment
Hide comment
@anon17

anon17 Mar 7, 2018

Downgrading to 3.1.10 helped me too.

anon17 commented Mar 7, 2018

Downgrading to 3.1.10 helped me too.

@anon17

This comment has been minimized.

Show comment
Hide comment
@anon17

anon17 Apr 5, 2018

Running under mono 5.10 gives a more descriptive error message:

System.BadImageFormatException: Could not resolve field token 0x0400052b, due to: Could not load type of field 'Npgsql.NpgsqlConnection+<Open>d__28:<>u__2' (7) due to: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:<unknown type> member:(null) signature:<none> assembly:Npgsql.dll type:<Open>d__28 member:(null) signature:<none>

But I can't find a way to install System.Runtime, libmono-system-runtime4.0-cil installs System.Runtime.Remoting.

anon17 commented Apr 5, 2018

Running under mono 5.10 gives a more descriptive error message:

System.BadImageFormatException: Could not resolve field token 0x0400052b, due to: Could not load type of field 'Npgsql.NpgsqlConnection+<Open>d__28:<>u__2' (7) due to: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:<unknown type> member:(null) signature:<none> assembly:Npgsql.dll type:<Open>d__28 member:(null) signature:<none>

But I can't find a way to install System.Runtime, libmono-system-runtime4.0-cil installs System.Runtime.Remoting.

@mikkeljohnsen

This comment has been minimized.

Show comment
Hide comment
@mikkeljohnsen

mikkeljohnsen Apr 5, 2018

I believe my problem was that I missed the "..../mono/4.5/Facades/" DLL files on Windows. Do you have them installed.

mikkeljohnsen commented Apr 5, 2018

I believe my problem was that I missed the "..../mono/4.5/Facades/" DLL files on Windows. Do you have them installed.

@anon17

This comment has been minimized.

Show comment
Hide comment
@anon17

anon17 Apr 5, 2018

I don't, I extracted them from the mac package. I put System.Runtime.dll and System.Threading.Tasks.dll facades into the application folder and it runs successfully on mono 5.10.

anon17 commented Apr 5, 2018

I don't, I extracted them from the mac package. I put System.Runtime.dll and System.Threading.Tasks.dll facades into the application folder and it runs successfully on mono 5.10.

@anon17

This comment has been minimized.

Show comment
Hide comment
@anon17

anon17 May 16, 2018

Ah, found it, reference assemblies are installed by the mono-devel package

anon17 commented May 16, 2018

Ah, found it, reference assemblies are installed by the mono-devel package

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Jun 9, 2018

Member

Closing as I couldn't reproduce the problem, and in any case it doesn't seem to be actually related to Npgsql.

Member

roji commented Jun 9, 2018

Closing as I couldn't reproduce the problem, and in any case it doesn't seem to be actually related to Npgsql.

@roji roji closed this Jun 9, 2018

@roji roji added the invalid label Jun 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment