Dapper: Upgraded to Dapper 1.50.7, now get FileNotFoundException from Dapper.SqlBuilder for Dapper 1.50.5

[jonsagara]

Will you be releasing an update of Dapper.SqlBuilder for Dapper 1.50.7? Is Dapper.SqlBuilder always tied to a specific version of Dapper?

Here is the exception I'm getting:

System.IO.FileNotFoundException: Could not load file or assembly 'Dapper, Version=1.50.5.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
File name: 'Dapper, Version=1.50.5.0, Culture=neutral, PublicKeyToken=null'
   at Dapper.SqlBuilder.Template.ResolveSql()
   at Dapper.SqlBuilder.Template.get_RawSql() in C:\projects\dapper\Dapper.SqlBuilder\SqlBuilder.cs:line 93

Thank you,

Jon

[mgravell]

We should release that, agreed. Job for tomorrow. Interim, a binding
redirect should work?

On Mon, 11 Feb 2019, 19:06 Jon Sagara, [e-mail] wrote:

Will you be releasing an update of Dapper.SqlBuilder for Dapper 1.50.7? Is
Dapper.SqlBuilder always tied to a specific version of Dapper?

Here is the exception I'm getting:

System.IO.FileNotFoundException: Could not load file or assembly 'Dapper, Version=1.50.5.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
File name: 'Dapper, Version=1.50.5.0, Culture=neutral, PublicKeyToken=null'
at Dapper.SqlBuilder.Template.ResolveSql()
at Dapper.SqlBuilder.Template.get_RawSql() in C:\projects\dapper\Dapper.SqlBuilder\SqlBuilder.cs:line 93

Thank you,

Jon

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/Dapper/issues/1191, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsEYegDm15nxsGRCJUJRAr12YVt3mks5vMb8bgaJpZM4a02Yu
.

[jonsagara]

I reverted to 1.50.5 for the time being. Thanks for the quick response!

[ongun23]

Is there any update for this issue? @mgravell

[JoJo2406]

Same issue with Dapper.Contrib still being on version 1.50.5

[gerbenvl]

Note that since dapper 1.50.7.0 the assembly version of Dapper.dll got changed to 1.50.0.0. Would have expected 1.50.7.0 there. Isn't this also causing these side effects?

[Omzig]

How often does this happen?

[gerbenvl]

Can't get binding redirect to work on .net core 2.2. So also downgraded tot 1.50.5.

[mgravell]

My understanding was that we had been pinning the assembly version for a
while, but it is possible that it wasn't previously pinned; in which case:
sorry. But: we should be pinning the assembly version going forward. We'll
try not to inconvenience folks too much!

On Wed, 13 Feb 2019, 17:47 gerbenvl, [e-mail] wrote:

Can't get binding redirect to work on .net core 2.2. So also downgraded
tot 1.50.5.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/Dapper/issues/1191#issuecomment-463297202,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsH-kfU9KrzV7K-JHxaxjF9YOCF0kks5vNE_GgaJpZM4a02Yu
.

[UweKeim]

Using Dapper.Contrib inside a pure console application (i.e. _no_ ASP.NET) in .NET Core 2.2, I'm getting a similar error:

System.IO.FileLoadException: 'Could not load file or assembly 'Dapper, Version=1.50.5.0, Culture=neutral, PublicKeyToken=null'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'

The call stack is inside:

at Dapper.Contrib.Extensions.SqlMapperExtensions.InsertAsyncT

Downgrading Dapper (i.e. _not_ Dapper.Contrib) from 1.50.7 to 1.50.5 does help as a workaround, too.

[NickCraver]

Apologies for a crazy busy week both at work and away on our end - 1.50.7 packages are publishing to NuGet now and should be listed shortly.

Can you please let us know if issues linger? It looks like assembly version pinning is correctly behaving (we intend to pin at 1.50.0.0 so that binding redirects each update aren't a pain point)...but honestly only .StrongName are strongly named in 1.x anyway (these libs will go away in 2.x). So it shouldn't matter. I admittedly don't fully understand the issue here since strong naming isn't in play...but maybe the people here are applying strong naming locally in their build and that's the source of the load error (looking for a specific version)? Regardless - let's see if just syncing them fixes whatever setup is in play here.

[UweKeim]

Works! Thanks a lot, @NickCraver, awesome library, awesome support! 👍

[jonsagara]

Verified fixed. Thanks!