"Wrong assembly binding redirects" when running BenchmarkDotNet - c#

When running BenchmarkDotNet for a method in my project I get a few "Wrong assembly binding redirect" warning/error messages printed to screen. This got me a bit puzzled, as I thought assembly binding redirects is a .Net Framework concept, while my projects are .Net Core 3.0. Googling the warning/error message gave no result. Any tips to what these messages mean, and possibly how to fix the problem. I tried cleaning Nuget cache, restoring Nuget packages, cleaning and rebuilding the solution, but to no help.
// BeforeAnythingElse
// Benchmark Process Environment Information:
// Runtime=.NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
// GC=Concurrent Workstation
// Job: DefaultJob
OverheadJitting 1: 1 op, 308100.00 ns, 308.1000 us/op
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en-US, PublicKeyToken=cc7b13ffcd2ddd51.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en, PublicKeyToken=cc7b13ffcd2ddd51.

The short answer is that you can ignore this warning.
The long answer: for some reason VS sometimes generates invalid assembly binding redirects for Full .NET Framework projects that reference .NET Standard libraries. It was causing a lot of trouble to BenchmarkDotNet users in the past:
https://github.com/dotnet/BenchmarkDotNet/issues/895,
https://github.com/dotnet/BenchmarkDotNet/issues/667,
https://github.com/dotnet/BenchmarkDotNet/issues/896,
https://github.com/dotnet/BenchmarkDotNet/issues/942 .
I decided to implement an ugly workaround that searches for .dll file manually and loads it when .NET Framework fails to do so.
Of course, this applies only to Full .NET Framework. When I was porting BenchmarkDotNet to .NET Standard 2.0 I've forgotten that we don't need to do this for .NET Core. As the end result, you get this confusing warning.
I've sent a PR that fixes that: https://github.com/dotnet/BenchmarkDotNet/pull/1365 and this workaround will now be executed only for Full .NET Framework projects

Related

Strange DLL loading behavior in Powershell 7

I've managed to boil down my test to a simple command:
PS C:\Users\CpUser> [System.Reflection.Assembly]::LoadFrom("C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\net45\NJsonSchema.dll")
MethodInvocationException: Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'NJsonSchema, Version=10.4.0.0, Culture=neutral, PublicKeyToken=c2f9c3bdfae56102'."
I'm using 64-bit Powershell v7.1.3 on Windows 10. Ran as administrator. It's not able to load the DLL I gave it, which is very odd to me. It also does not give me any detail as to why it cannot load it. When I try a lower version of NJsonSchema.dll, it works, but it loads it from an unexpected location:
PS C:\Users\CpUser> [System.Reflection.Assembly]::LoadFrom("C:\Users\CpUser\.nuget\packages\njsonschema\9.10.52\lib\net45\NJsonSchema.dll")
GAC Version Location
--- ------- --------
False v4.0.30319 C:\Program Files\PowerShell\7\NJsonSchema.dll
It's loading it from C:\Program Files\Powershell\7 which seems wrong to me. I sent to the Properties -> Details of that DLL and it says it is version 10.2.2. What it seems like is happening here is:
Powershell takes the version of the assembly I provided in the LoadFrom() call
It searches C:\Program Files\PowerShell\7 for the same DLL with a version equal to or greater than the version obtained in the previous step
If not found, fail.
What I expect is for it to load the DLL using the absolute path I gave it.
As a workaround, I found another solution that does seem to work:
$AssemblyPath = "C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\net45\NJsonSchema.dll"
$bytes = [System.IO.File]::ReadAllBytes($AssemblyPath)
[System.Reflection.Assembly]::Load($bytes)
I get a successful result when I run the above in a script:
PS C:\Users\CpUser> .\testLoadDll.ps1
GAC Version Location
--- ------- --------
False v4.0.30319
So I feel like this rules out any issues with the DLL itself. I'm completely lost here. Can someone explain the behavior I'm seeing and how to get the behavior I expect?
According to the documentation, for Assembly.LoadFrom Method
The LoadFrom method has the following disadvantages. Consider using
Load instead.
...
If an assembly is loaded with LoadFrom, and the probing path includes
an assembly with the same identity but a different location, an
InvalidCastException, MissingMethodException, or other unexpected
behavior can occur.
Update:
According to Resolving PowerShell module assembly dependency conflicts,
PowerShell and .NET
PowerShell runs on the .NET platform. NET is ultimately responsible
for resolving and loading assembly dependencies, so we must understand
how .NET operates here to understand dependency conflicts.
We must also confront the fact that different versions of PowerShell
run on different .NET implementations. In general, PowerShell 5.1 and
below run on .NET Framework, while PowerShell 6 and above run on .NET
Core. These two implementations of .NET load and handle assemblies
differently. This means that resolving dependency conflicts can vary
depending on the underlying .NET platform.
Therefore, ensure you are loading the DLL in the netstandard2.0 folder, if using Powershell version 6 and above.
Try the following:
Open PowerShell version 7.1.3:
In "Type here to search" box, enter pwsh
Right-click PowerShell 7 (x64)
Select Run as administrator
Get PowerShell version:
Get-Host | Select-Object Version
Get Loaded Assemblies:
[System.AppDomain]::CurrentDomain.GetAssemblies()
Load NJsonSchema.dll:
Note: Since we're using PowerShell 7.x.x, use the NJsonSchema.dll file in the netstandard2.0 folder.
$Assembly = [System.Reflection.Assembly]::Loadfile('C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\netstandard2.0\NJsonSchema.dll')
Get Loaded Assemblies (again):
[System.AppDomain]::CurrentDomain.GetAssemblies()
Check the version of NJsonSchema.dll:
$Assembly.GetName()

Error: "The module cannot be loaded because only single file assemblies are supported" in .NET Core

Despite having a several years background in .NET backend, I'm a newbie in cross-platforms, hence in .NET Core.
I'm struggling the below error during runtime of the component developed in .NET Core 3.1 framework which is a worker service (introduced in .NET Core 3.x).
Any ideas folks?
Important: This .netmodule file is already being utilized in our current backend in .NET environment bundled with another .dll assembly file(s). I know that most of the .NET 3rd party libraries are NOT compatible with .NET Core area. However, I'm not sure whether there's a hidden catch on the issue; since when I google'd the error message, I could not find any exact match.
System.IO.FileLoadException: Could not load file or assembly 'dcpssacs.netmodule'. The module cannot be loaded because only single file assemblies are supported. (0x8013101E)
File name: 'dcpssacs.netmodule'
at DDSMessageReceiver.Core.GenericSimplicityLayer.DefaultSettings(BaseModel& baseModel)
at DDSMessageReceiver.Worker.InitializeModules() in C:\Triodor_Workspace\T4CNext\DDSMessageReceiver\DDSMessageReceiver\Worker.cs:line 83
at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__139_1(Object state)
at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

VS2017 .NetCore 2.0 API - Could not load file or assembly Microsoft.AspNetCore.Hosting.Abstractions

I've just created a new API using ASP.NET Core 2.0.
I haven't coded anything yet. I just want to test the initial API template.
When I try to start my project I receive the following error:
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in Unknown Module.
Could not load file or assembly 'Microsoft.AspNetCore.Hosting.Abstractions, Version=2.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
I do not receive any errors when building the project.
The assemby can be found at the following directory: 'C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.hosting.abstractions\2.0.2'.
Is that correct? Where should the 'Microsoft.AspNetCore.Hosting.Abstractions' assembly be located and why can't VS find it?
I had the same error attempting to debug a simple Azure Function App (this is using .NET core) created from the Function App template in Visual Studio 2017. Attempting to run in debugger gave me the same error. It turned out to be I had updated the Microsoft.NET.Sdk.Functions package from version 1.0.6 to 1.0.12. That was my problem. Reverted the update back to 1.0.6 and it worked fine. Hope this helps!
Please re-install the nuget package or upgrade to the latest at: https://www.nuget.org/packages/Microsoft.AspNetCore.Mvc.Abstractions/

ASP.NET Boilerplate .NET Core 2

Trying to upgrade ASP.NET Boilerplate project from .NET Core 1.x to .NET Core 2.0
Solution builds successfully, but throws exception in Startup.ConfigureServices method at
services.AddAbpIdentity<Tenant, User, Role, SecurityStampValidator>(
options => {})
.AddUserManager<UserManager>()
.AddRoleManager<RoleManager>()
.AddSignInManager<SignInManager>()
.AddClaimsPrincipalFactory<UserClaimsPrincipalFactory>()
.AddDefaultTokenProviders();
Exception details
System.TypeLoadException: 'Could not load type 'Microsoft.AspNetCore.Authentication.SharedAuthenticationOptions' from assembly 'Microsoft.AspNetCore.Authentication, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.'
You should wait ABP v3.0. We have released ABP v3.0.0-beta2. If you want, you can use beta version.
You also need to change your solution for:
https://learn.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/
https://learn.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/identity-2x
Fortunately, I upgraded solution template. So, you can see all changes I done:
https://github.com/aspnetboilerplate/module-zero-core-template/pull/106/files

How should I be using Npgsql in Appharbor?

I've developed a quick and simple app on my local machine using SQLite to get started. Now that I'm in the middle of working out how to upload to AppHarbor, I'm a bit stuck on getting the link to ElephantSQL to work.
I used the Application PostgreSQL Sample Application to determine that I needed to use the PostgreSQLConfiguration class for my FluentNHibernate configuration and install the Npgsql package to my solution (I got version 2.0.12.1).
When I push the code up to AppHarbor, it builds and deploys happily. When the server starts to spin up the AppDomain, it throws the error Could not load file or assembly 'policy.2.0.Npgsql' or one of its dependencies. Modules which are not in the manifest were streamed in. (Exception from HRESULT: 0x80131043). This isn't logged in the Errors section of the AppHarbor dashboard (perhaps this is a missing feature or a bug?) so I had to turn off CustomErrors to figure out what was going on.
What have I missed?
Additional - I tried downgrading to package version 2.0.11. This did not include the policy.2.0.Npgsql.dll file and when trying to load the app, it fails with the error Unable to find the requested .Net Framework Data Provider. It may not be installed..
I got it working by going down to version 2.0.11 and made sure that the DbProviderFactories configuration section had the correct version number in the type attribute.
<DbProviderFactories>
<add name="Npgsql Data Provider" invariant="Npgsql" description=".Net Framework Data Provider for PostgreSQL Server" type="Npgsql.NpgsqlFactory, Npgsql, Version=2.0.11.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7" />
</DbProviderFactories>
I was running npgsql 2.0.13 beta (December 2013) on AppHarbor and was getting hosed by this issue for a little while, till I discovered that it's not needed if you're running the latest assembly and don't care about bindingRedirects - it's a dll generated by the .net AL.exe/assembly linker tool to roll up the contents of the policy.2.0.Npgsql.config file (check out https://github.com/npgsql/Npgsql/blob/master/src/policyFileBuild.bat to see how that's compiled).
MY CONFIGURATION:
VS2012
.net 4.5
MVC4
Entity Framework 6 (installed via nuget package restore)
npgsql - 2.0.13.91 (installed via nuget package restore)
THE HACKY FIX:
By Deleting it from the build as a post build event (Project Menu --> Properties --> Build Events --> Post Event Command Line), you can bypass the error (which I don't know why doesn't work on AppHarbor).
So add this nonsense:
del $(TargetDir)policy.2.0.Npgsql.dll /F
del $(TargetDir)policy.2.0.Npgsql.config /F
dir $(TargetDir)
del $(TargetDir)_PublishedWebsites\<appname/>\bin\policy.2.0.Npgsql.dll
del $(TargetDir)_PublishedWebsites\<appname/>\bin\policy.2.0.Npgsql.config
dir $(TargetDir)_PublishedWebsites\<appname/>\bin\
This is probably over-kill, but note that the dir dos command statement gives you feedback on the contents of your directories to make sure the files have actually been deleted. This is viewable from Show Log of build activities in AppHarbor.
Regarding the 2 sets of deletes on dll and config from that god awful msbuild packaging routine (/output directory and the /output/_PublishedWebsites) - IMHO - it's better to be thorough if you're killing stuff, but it may be sufficient to simply delete only from _publishedwebsites...
When it gets built in AppHarbor, this will chuck it from the targeted deployment. You might have to wait for a few minutes for the deploy to complete, but it's absence from the deploy will unblock you.
I think this nuget package is missing the policy.2.0.Npgsql.dll file. Can you install the package for 2.0.12 version from official nuget Npgsql package? It has the missing file.
I hope it helps.

Categories

Resources