TFS have issued the following warning:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(1605): There was a mismatch between the processor architecture of the
project being built "MSIL" and the processor architecture of the
reference
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Data.dll",
"AMD64". This mismatch may cause runtime failures. Please consider
changing the targeted processor architecture of your project through
the Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on
references with a processor architecture that matches the targeted
processor architecture of your project.
Both "Release" and "Debug" configurations are set to use "Any CPU" as an active solution platform.
I took a copy of System.Data.dll into the TEMP folder and extracted information about this assembly through PowerShell:
function ScanAssembly($assemblyPath) {
[reflection.assemblyname]::GetAssemblyName($assemblyPath)
}
$assemblyPath = "C:\TEMP\System.Data.dll"
$assemblyInfo = ScanAssembly($assemblyPath);
$assemblyInfo | fl;
I got the following output:
Name : System.Data
Version : 4.0.0.0
CultureInfo :
CultureName :
CodeBase : file:///C:/TEMP/System.Data.dll
EscapedCodeBase : file:///C:/TEMP/System.Data.dll
ProcessorArchitecture : Amd64
ContentType : Default
Flags : PublicKey
HashAlgorithm : SHA1
VersionCompatibility : SameMachine
KeyPair :
FullName : System.Data, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=...
For some reason, the ProcessorArchitecture for this assembly is set to Amd64. I'm confused as to why it's set to Amd64, because I'm running a 64-bit operating system on an Intel processor.
These warnings are not show stoppers, but I'm struggling to understand as to why we are seeing them. If I understand this correctly, the configuration is set to any CPU, when one of the assemblies is compiled for Amd64, which implies that it will no longer work on any CPU - it'll work only on 64 bit CPU. Why the System.Data.dll is built for Amd64 is beyond me.
Thank you.
You're correct about why these errors are occurring. If a referenced assembly targets a specific framework, the compiler warns that your application can't run on "Any CPU" because the referenced assembly has limitations.
We had this issue on our test and production servers with System.Data and other DLLs. We resolved it by installing the .Net Framework SDK. To do that:
Find the correct SDK. Our environments are set up with Windows Server 2008 and .Net Framework 4.5, so we used the Windows 8 SDK.
Install only the .Net Framework 4.5 SDK (after you accept the license, there's a screen with several checkboxes; I only left the last one checked).
The SDK adds a new version of System.Data.dll in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5. Examining that assembly, you can see that the ProcessorArchitecture is set to None.
Name : System.Data
Version : 4.0.0.0
CultureInfo :
CultureName :
CodeBase : file:///C:/Program Files (x86)/Reference\Assemblies/Microsoft/Framework/.NETFramework/v4.5/System.Data.dll
EscapedCodeBase : file:///C:/Program%20Files%20(x86)/Reference%20Assemblies/Microsoft/Framework/.NETFramework/v4.5/System.Data.dll
ProcessorArchitecture : None
ContentType : Default
Flags : PublicKey
HashAlgorithm : SHA1
VersionCompatibility : SameMachine
KeyPair :
FullName : System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The other option is to configure your project to target 64-bit processors if that's an option, but our team chose to go the SDK route.
Related
I found this same issue in my research, but no solution was found: Research Link
This .dll is System.net.http, and it is pulled from the 4.6.1 .NET Framework. I am trying to create an assembly out of it in SQL Server 2017.
I've done the following steps:
Create a certificate (THIS TELLS ME WARNING: Certificate is expired)
Create a login
Grant unsafe assembly
Also set the database I'm running this on to TRUSTWORTHY
Set CLR security to 0, tried installing assembly (failed)
This is the code I'm executing:
CREATE CERTIFICATE [MS.NETcer]
FROM EXECUTABLE FILE =
'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.net.http.dll';
CREATE LOGIN [MS.NETcer] FROM CERTIFICATE [MS.NETcer];
GRANT UNSAFE ASSEMBLY TO [MS.NETcer];
create ASSEMBLY [System.Net.Http]
FROM 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.net.http.dll'
WITH PERMISSION_SET = UNSAFE
This is my issue:
Msg 6218, Level 16, State 2, Line 15
CREATE ASSEMBLY for assembly 'System.Net.Http' failed because assembly 'System.Net.Http' failed verification. Check if the referenced assemblies are up-to-date and trusted (for external_access or unsafe) to execute in the database. CLR Verifier error messages if any will follow this message
[ : System.Net.Http.SR::.ctor][mdToken=0x6000001][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_ResourceManager][mdToken=0x6000002][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_Culture][mdToken=0x6000003][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::set_Culture][mdToken=0x6000004][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_argument_empty_string][mdToken=0x6000005][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_absolute_baseaddress_required][mdToken=0x6000006][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_content_headers][mdToken=0x6000007][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_execution_error][mdToken=0x6000008][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_http_baseaddress_required][mdToken=0x6000009][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_invalid_requesturi][mdToken=0x600000a][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_request_already_sent][mdToken=0x600000b][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_request_headers][mdToken=0x600000c][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_response_headers][mdToken=0x600000d][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_send_canceled][mdToken=0x600000e][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net_http_client_send_completed][mdToken=0x600000f][offset 0x00000000] Code size is zero.
[ : System.Net.Http.SR::get_net...
Edit 1: If I use the .dll from the 4.7.2 framework instead, I get the following error:
Msg 6586, Level 16, State 1, Line 18
Assembly 'System.Net.Http' could not be installed because existing policy would keep it from being used.
Edit 2: If I follow the advice below and pull the .dll (instead of from the reference folders) from C:\Windows\Microsoft.NET\Framework64\v4.0.30319, I get this problem instead.
Msg 6522, Level 16, State 1, Procedure DataRobot.pDataUpload, Line 0 [Batch Start Line 47]
A .NET Framework error occurred during execution of user-defined routine or aggregate "pDataUpload":
System.IO.FileLoadException: Could not load file or assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Assembly in host store has a different signature than assembly in GAC. (Exception from HRESULT: 0x80131050) See Microsoft Knowledge Base article 949080 for more information.
System.IO.FileLoadException:
at DataRobot.DataUpload.Upload(String directory, String proxyAddress, String apiToken)
Edit 3: Following up #Solomon to provide additional context. I build my project on my work computer. The SQL Server is hosted on a different server. The .NET libraries I use are on my local C:\ drive. These are the facts so far:
I compile my project as a .dll to a SQL Server shared drive
I copy and paste the System.net.http.dll library to the same SQL Server shared drive.
I add the System.net.http.dll as a certificate. Database is also set to TRUSTWORTHY.
I create assemblies and stored procedure to run the methods in my compiled project .dll.
You are probably pointing to a reference assembly and not the actual assembly with the actual code in it (hence the "Code size is zero." error message).
If you are using SQL Server 2012 or newer, then the following does work (and does not require setting the DB to TRUSTWORTHY ON, so turn TRUSTWORTHY back to OFF):
USE [master];
CREATE CERTIFICATE [MS.NETcer]
FROM EXECUTABLE FILE =
'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Net.Http.dll';
CREATE LOGIN [MS.NETcer] FROM CERTIFICATE [MS.NETcer];
GRANT UNSAFE ASSEMBLY TO [MS.NETcer];
USE [SomeUserDB];
CREATE ASSEMBLY [System.Net.Http]
FROM 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Net.Http.dll'
WITH PERMISSION_SET = UNSAFE;
Regarding Edit:
If I use the .dll from the 4.7.2 framework instead, I get the following error:
Do not try to use a specific .NET Framework version of a .NET Framework library. You need to use what is currently on the server running SQL Server since the version that SQL Server is using must match the version that the OS is using. So, for system assemblies it is best to pull from disk (i.e. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ ).
Regard Edit 2:
If I follow the advice and pull the .dll from C:\Windows\Microsoft.NET\Framework64\v4.0.30319, I get this problem instead.
Assembly in host store has a different signature than assembly in GAC.
Hmm. I would think the GAC would get its version from that same directory. Is it possible that there was a Windows Update that updated the version on disk and the GAC hasn't been refreshed yet? Or something like that? Can you rebooting the server and then try loading the assembly again?
Regarding Edit 3:
I copy and paste the System.net.http.dll library to the same SQL Server shared drive.
No, no, no. Do not copy/paste any .NET Framework DLL. You need to use the version that is on the same server as SQL Server. This is why you need to execute the statements that I provided above (i.e. CREATE ASSEMBLY [System.Net.Http] FROM 'C:\Windows\Microsoft.NET\Framework64\... ). It doesn't matter if you compile your project against .NET 4.5.2 and the server hosting SQL Server has .NET 4.8 installed. Just load the .NET Framework DLL from the server running SQL Server, then load your DLL. The only time a version difference matters between what you compile against and what SQL Server is using (based on the server it's running on) is if you are developing on a machine with a newer version of .NET Framework that has a new feature not found in the version being used by SQL Server. And in that case (which is rare to happen), you simply need to update the version of .NET Framework on the server running SQL Server.
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()
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
I'm using the GAC to share dll's.
Here, I have an application that use the Microsoft.Practices.EnterpriseLibrary.Data.dll 5.0.414.0. if I put it on the same folder than the .exe, all is OK, but when I want to remove it from this folder, it doesn't working, even if I installed it on the GAC...
I installed it on the GAC thanks to
D:\Applications\Services\App>GACUTIL.exe -i Microsoft.Practices.EnterpriseLibrary.Data.dll
Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Assembly successfully added to the cache
When I remove this dll from this folder, the app isn't run correctly, why?
I tried the GAC woth others dll's and it's ok, and When I go to C:\WINDOWS\assembly, the dll looks like it's installed!
I already re-tryed to install it with the CLI that I shown you before.
EDIT:
Type:
Exception type:
Microsoft.Practices.ServiceLocation.ActivationException, Microsoft.Practices.ServiceLocation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Message:
Activation error occured while trying to get instance of type LogWriter, key ""
Stack:
Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance(Type serviceType, String key)
Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance[TService]()
Microsoft.Practices.EnterpriseLibrary.Logging.Logger.get_Writer()
MyFramework.Logging.MyLogger.WriteVerbose(String applicationName, String title, String logText)
MyApp.Fleet_Service.GetInfo(Int32 accountid, String[] msisdns, DateTime from, DateTime to) in c:\Clients\Project\V1\Fleet_Service.cs:line 111
SyncInvokeGetInfo(Object , Object[] , Object[] )
Thanks to help me
Depending on the .NET version you are using, the GAC might not be in C:\Windows\Assembly.
For .NET 4, the GAC is located at %windir%\Microsoft.NET\assembly\.
In general, if you want to understand why a .NET application does not find an assembly, you should use the Assembly Binding Log Viewer tool (fuslogvw.exe from a VS command prompt).
EDIT: after seeing your comment, it could be that it's not your application directly that is trying to load the assembly that fails, but maybe some other dll. Use the assembly binding log viewer tool to determine what is failing and why. Also, it would be better if you provided some more details on how your application is failing (error message, stack trace...)
Here's the code that raises the exception
public Configuration GetConfiguration()
{
var persister = SQLiteConfiguration
.Standard
.UsingFile("Test.db")
.ShowSql();
var configuration = Fluently
.Configure()
.Database(persister)
.Mappings(map => map.FluentMappings.AddFromAssemblyOf<WordMap>())
.BuildConfiguration();
new SchemaExport(configuration).Execute(true, true, false);
return configuration;
}
The full exception text:
Failure: NHibernate.HibernateException : Could not create the driver
from NHibernate.Driver.SQLite20Driver, NHibernate, Version=2.1.2.4000,
Culture=neutral, PublicKeyToken=aa95f207798dfdb4.
----> System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
----> NHibernate.HibernateException : The IDbCommand and IDbConnection implementation in the assembly System.Data.SQLite could
not be found. Ensure that the assembly System.Data.SQLite is located
in the application directory or in the Global Assembly Cache. If the
assembly is in the GAC, use element in the
application configuration file to specify the full name of the
assembly.
Version of NHibernate is 2.1.2.4000
Version of System.Data.SQLite is 1.0.66.0
Target Framework is 3.5 (x86)
Local copy for System.Data.SQLite is ON.
What may be wrong?
Just copy System.Data.SQLite.dll library to the the base directory of your application (especially where NHibernate.dll library is placed).
You even don't need it to add as reference under VS.
Regards
Bronek
I just installed the SQLite NuGet package and that worked for me.
I got rid of this issue by adding useLegacyV2RuntimeActivationPolicy="true" to app.config. See Problem Upgrading NHibernate SQLite Application to .Net 4.0
Could not create the driver from NHibernate.Driver.SQLite20Driver, NHibernate, Version=2.1.2.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4
Solution:
testsettings:
choose hosts
choose run tests in 64 bit process on 64 bit machine
hoping I could help.
merry coding
If LocalCopy is on, is it on for a version of System.Data.SQLite in the start-up project because that's where it'll be looking for it, not in the bin directory of a sub-project.
In VS 2019, in Test -> Processor Architecture for AnyCPU Projects, I changed from x64 to Auto and it solved my problem.