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()
Related
I have a problem only on a specific machine.
I have two programs with a reference to Sap.Data.Hana.v4.5.dll, the ADO.NET Provider for .NET 4.5 for HANA database.
When my programs instantiates a connection object with
dbConnection = new HanaConnection(...);
I get this error:
System.TypeInitializationException: The type initializer for 'Sap.Data.Hana.HanaConnection' threw an exception. ---> System.IO.FileNotFoundException: Cannot find libADONETHDB.dll.
at Sap.Data.Hana.HanaUnmanagedDll.SearchNativeDlls(String regKeyName)
at Sap.Data.Hana.HanaUnmanagedDll..ctor()
at Sap.Data.Hana.HanaUnmanagedDll.get_Instance()
at Sap.Data.Hana.HanaConnection..cctor()
--- End of inner exception stack trace ---
at [...my program calls...]
Why can't it find libADONETHDB.dll?
My applications are build one in 32-bit, the other in 64-bit.
On this machine I installed SAP HANA client 2.8.20.23662 (latest version) both 32-bit and 64-bit.
The file that cannot be found seems to exist:
You could use Process Monitor while running the relevant part of the program to see, which file is missing and the path it should be in. Exclude all other events than file events and filter out all SUCCESS messages.
Perhaps it is referenced relative to the calling DLL (where Sap.Data.Hana.HanaUnmanagedDll.SearchNativeDlls is defined).
My hipotesis is that GAC had been corrupted with version 1 of Sap.Data.Hana.v4.5.dll:
Probably in the past HANA Client version 1 had been installed and removed and uninstallation hadn't cleaned the GAC.
My program uses HANA Client of any version, works both with version 1 and 2. For some reason when they start they seem to take version 1 of Sap.Data.Hana.v4.5.dll in the GAC. Process Monitor (thanks #sc911) confirms it:
This .NET DLL then looks for some unmanaged DLLs in C:\Program Files (x86)\hdbclient. Version 1 seems to look for libADONETHDB.dll in root folder.
But currently in this machine in that folder we have HANA Client 2.x and its folder structure is quite different from that of version 1 (there is no libADONETHDB.dll in root folder).
Hence the error in this question.
All this is valid both for 32-bit and 64-bit HANA Client.
I solved renaming or deleting version 1 folder in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Sap.Data.Hana.v4.5 (probably there are better ways for performing this cleanup).
I try to connect to a fiscal device with a C#.
I use this documentation to do so: http://integration.atol.ru/api-en/#connection-to-project
So basically I have a driver of the device installed on my PC (fprt10.dll) and there is a "wrapper" assembly that allows me to work with this driver from C# (Atol.Drivers10.Fptr.dll). I import this wrapper into my project as a reference.
I have the following constructor in my class:
public MyClass()
{
IFptr fiscalPrinter = new Fptr();
// Here comes several settings to configure connection
fiscalPrinter.applySingleSettings();
fiscalPrinter.open();
fiscalPrinter.beep();
fiscalPrinter.close();
}
To test the solution I use another application, that loads my Class Library as a dependency.
When I call a constructor of MyClass I get an exception:
System.IO.FileNotFoundException: Driver not installed
at Atol.Drivers10.Fptr.Fptr.loadDriver(String path)
at Atol.Drivers10.Fptr.Fptr..ctor()
at MySolution.MyClass.MyClass()
...
If I create instance of Fptr with a path to the driver
IFptr fiscalPrinter = new Fptr(#"C:\path\fptr10.dll")
I get the slightly different exception, but I believe the problem is the same:
System.IO.FileNotFoundException: Can`t load driver library "C:\path\fptr10.dll"
at Atol.Drivers10.Fptr.Fptr.raiseNotFoundError(String path, Exception reason)
at Atol.Drivers10.Fptr.Fptr.loadDriver(String path)
at Atol.Drivers10.Fptr.Fptr..ctor(String libraryPath)
at MySolution.MyClass.MyClass()
...
But when I create a Console Application and put in there exact same code (both versions with path and without), everything works: the device beeps, there are no exceptions.
What could be the reason for that behavior and how to fix this?
The issue may be one of the following
The test application is using 'target platform' different than the console application which works fine. The device driver folders expected for each platform could be different. e.g. Changing the targeted platform from 'any CPU' to 'x64' / 'x86' (depending on the type of OS where you are running it) will help
Try running the test application from admin command prompt. Permissions issue may reflect as 'file not found' (instead of 'file could not be loaded').
Use an assembly binding viewer tool to debug the issue further
Refer to Could not load file or assembly or one of its dependencies for more discussion and inputs on the assembly loading issues.
Thank you samiksc.
The issue was in the test app. The driver and OS that I use are both x64, but the test application is x86. With x86 driver everything works.
In my program I have this simple code:
using System;
using System.Data;
using Mono.Data.SqliteClient;
....
IDbConnection cnx = new SqliteConnection("URI=file:reestr.db");
cnx.Open();
....
And this is how I compile it:
$ mcs Test.cs -r:System.Data.dll -r:mono.data.sqliteclient.dll
It compiles ok. But when I run it with ./Test.exe, I get this error messages:
Missing method .ctor in assembly ....
Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Data.SqliteClient, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies.
File name: 'Mono.Data.SqliteClient, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756'
I'm not sure what I'm doing wrong here and how to repair it.
PS. I'm using Ubuntu as my OS.
It appears that Mono.Data.SqliteClient can not find the native SQLite binaries:
Prerequisites If you do not have SQLite, download it. There are
binaries for Windows and Linux. You can put the .dll or .so along side
your application binaries, or in a system-wide library path.
Ref: http://www.mono-project.com/docs/database-access/providers/sqlite/
To obtain pre-compiled native binaries (or source) for your platform:
http://www.sqlite.org/download.html
Also if you have the SQLite native shared libraries installed, are they available via dlopen? If not, you can assign the LD_LIBRARY_PATH env. var so Mono can find them at runtime.
Linux Shared Library Search Path From the dlopen(3) man page, the
necessary shared libraries needed by the program are searched for in
the following order:
A colon-separated list of directories in the user’s LD_LIBRARY_PATH
environment variable. This is a frequently-used way to allow native
shared libraries to be found by a CLI program. The list of libraries
cached in /etc/ld.so.cache. /etc/ld.so.cache is created by editing
/etc/ld.so.conf and running ldconfig(8). Editing /etc/ld.so.conf is
the preferred way to search additional directories, as opposed to
using LD_LIBRARY_PATH, as this is more secure (it’s more difficult to
get a trojan library into /etc/ld.so.cache than it is to insert it
into LD_LIBRARY_PATH). /lib, followed by /usr/lib.
Ubuntu Notes:
$ sudo apt-get install sqlite
$ ls -1 /usr/lib/libsqlite*
/usr/lib/libsqlite.so.0
/usr/lib/libsqlite.so.0.8.6
$ export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH
$ mono ./Test.exe
I solve the problem in my Mac in this way. Right Click in Mono.Data.Sqlite on References and click in Local Copy. This make mono copy dll to debug folder and your application will find the library.
OBS: Sorry for my bad english.
I've added a reference to the CUDAfy.NET library via NuGet.
<package id="CUDAfy.NET" version="1.12.4695.21111" targetFramework="net45" />
When I run my program, I hit a Win32Exception:
The system cannot find the file specified
This happens on the first actual line of the program:
CudafyModule km = CudafyTranslator.Cudafy();
There's no indication from the exception object as to what file they're attempting to load.
How can I get past this problem?
EDIT
I see the same exception when running the bundled examples from the Codeplex download in VS2010 using .NET 4.0.
The strack trace is:
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at Cudafy.CudafyModule.Compile(eGPUCompiler mode, Boolean deleteGeneratedCode)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Version cudaVersion, Boolean compile, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy()
Setting VS to break on thrown exceptions shows the ProcessStartInfo object at the top of the stack in the locals pane of the debugger.
The relevant properties are:
FileName = nvcc
Arguments = -m64 -arch=sm_12 "c:\<path>\CUDAFYSOURCETEMP.cu" -o "c:\<path>\CUDAFYSOURCETEMP.ptx" --ptx
Some information from this article explains that the CUDA Toolkit must be installed. Fair enough.
Ensure that the C++ compiler (cl.exe) is on the search path. This set-up of NVCC is actually the toughest stage of the whole process, so please persevere. Read any errors you get carefully - most likely they are related to not finding cl.exe or not having either 32-bit or 64-bit CUDA Toolkit.
That article discusses version 4 of the toolkit, but version 5 is available now and supported since CUDAfy v1.1.
Download from https://developer.nvidia.com/cuda-downloads
Note that the 64-bit version of the CUDA Toolkit 5.0 is a 942 MB download. If you install everything you'll need an additional 2815 MB. The toolkit alone requires 928 MB.
EDIT After installing the CUDA Toolkit 5.0, the program failed with a CudafyCompileException at the same source line:
Compilation error: nvcc : fatal error : Cannot find compiler 'cl.exe' in PATH
Searching my system drive:
C:\>dir /s cl.exe
This shows many different versions of the compiler/linker, both from VS 10.0 and 11.0. Apparently only cl.exe versions 9 and 10 are supported, so I opted for the VS10.0 amd64 version, I included the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
Your path may be different, depending upon your CPU. I recommend running the search to see your options.
Note that you will have to restart VS after changing the PATH environment variable if you already have it open.
After taking these steps, my basic program ran successfully.
This may also happen if you had at some point installed CUDA Toolkit v7.5, but realized that the most recent version of CUDAfy supports CUDA 7.0.
On uninstalling CUDA 7.5 from the control panel, some files/folders may still remain. You should delete these manually. You may use CUDAfyViewer to see which version of CUDA Toolkit is being accessed.
I have a project that was built in Visual Studio 2005 in C#. I created an installer for the Windows application (in VS2010) and it installs and works fine on Windows XP SP3. I tried installing it on Windows 7 32-bit and it says installation is successful but when I try to open the application I receive this error message:
A fatal error has occurred. Unable to load DLL 'VistaDb20.dll': Invalid
access to memory location. (Exception from HRESULT: 0x800703E6)
People suggested I run this in the command line:
regsvr32 VistaDb20.dll
I get the error message:
The module "VistaDb20.dll" was loaded but the
entry-point DllRegisterServer was not found.
Make sure that "VistaDb20.dll" is a valid DLL or OCX
file and then try again.
So then I tried regasm VistaDb20.dll /tlb:VistaDb20.tlb using the .NET Framework Assembly Registration Utility 2.0.50727.4927 and get error:
RegAsm : error RA0000 : Failed to load 'VistaDb20.dll' because it is not a valid .NET assembly.
I am not sure how to get my application running on Windows 7 with this .dll problem. Any help would be appreciated. This application and the database was created using VistaDB 2.1
I guess I can't change the actual dll since I did not create it but maybe I have to change some properties of the dll in Visual Studio?
I had this error while trying to registering my VB .NET assembly using RegAsm command:
RegAsm : error RA0000 : Failed to load 'VistaDb20.dll' because it is not a valid .NET assembly.
I solved the problem buy executing RegAsm of the right .NET Framework.
I mean you should use the tools of the same Framework that you make as target in your advanced options of compilation (VS2010).
According to this your problem is that this DLL is not compatible with DEP. You'll need to disable DEP to workaround this but in the long term you should try to wean yourself off this particular dependency.