I created the following Github repo to document the problem:
https://github.com/red-swan/fake-sqlite-problem
I am unable to build sqlite databases from an F# FAKE file relying on Paket. Adding the nuget package System.Data.SQLite to the paket.dependencies means I can open System.Data.SQLite but when attempting to build a database from the build.fsx file, I get the following error:
(Unable to load DLL 'SQLite.Interop.dll' or one of its dependencies: The specified module could not be found. (Exception from HRESULT: 0x8007007E))
SQLite.Interop.dll is a located in dependency runtimes\win-x64\native\netstandard2.0 of System.Data.SQLite's dependency System.Data.SQLite.Core. Trying to reference it directly with and #r statement in the build.fsx fails with the error:
Error opening binary file ... bad cli header, rva
I'm not sure how everything is supposed to resolve, but running the database creation from an actual fsproj works just fine, so I believe it has do with the FAKE or Paket resolution.
If you are familiar with FAKE, does this sound reasonable? Do you know how to fix this?
To reproduce the error:
git clone https://github.com/red-swan/fake-sqlite-problem.git
The above comment by TeaDrivenDev has the solution. I'm putting the answer here so I can close the question.
To be specific, I found the Native dll SQLite.Interop.dll and dropped it into the root folder where the FAKE build.fsx file is. The article TeaDrivenDev references has alternative methods as well.
Related
I am new in Cmake thats why I will write story detailed.
I trying to build one lib under windows and that lib depends on other lib. (libmatroska depends on libebml) source libmatroska and source libebml
Fortunately both libs can be build with cmake.
I built libebml successfuly with cmake. And also built binaries using VS studio.
Then I tried to deal with libmatroska:
During first try I got:
Could not find a package configuration file provided by "Ebml" (requested
version 1.3.5) with any of the following names:
EbmlConfig.cmake
ebml-config.cmake
at libebml sources I found EbmlConfig.cmake.
I Type export Ebml_DIR=D:/work/mkv/libebml and try again.
On second run I got:
Could not find a configuration file for package "Ebml" that is compatible
with requested version "1.3.5".
The following configuration files were considered but not accepted:
D:/work/mkv/libebml/EbmlConfig.cmake, version: unknown
And after few hours I am still stuck on it.
I can't understand root of this error.
Is it something wrong with EbmlConfig.cmake?
... or maybe I specified path to wrong *.cmake file?
... or I need to install libebml some how before handling libmatroska?
I will be happy for any clue.
UPDATE:
Here EbmlConfig.cmake context:
include(${CMAKE_CURRENT_LIST_DIR}/EbmlTargets.cmake)
Where EbmlTargets.cmake is file generated while Ebml compilation.
I tried to change path inside EbmlConfig.cmake to global path. But got same error.
Also when I delete context of EbmlConfig.cmake I still have same error.
It looks like "default error when something goes wrong"
I have a library project called MyLib, in which I have a namespace called Extensions, in which there is a module called Extension1, which has a method called ext1Method1 of type string -> string.
In the solution for the library project, there is an executable console project called Test. Within Test I can call MyLib.Extensions.Extension1.ext1Method1 str and it works fine.
I have created a completely separate solution called NewSol1 and included a reference to MyLib.dll in NewSol1. In NewSol1 there is a line
printfn "%s" (MyLib.Extensions.Extension1.ext1Method1 "Hello, World")
The solution NewSol1 builds without any error. But when I run the executable I get the following error:
System.MissingMethodException was unhandled
Message: An unhandled exception of type 'System.MissingMethodException' occurred in NewSol1.exe
Additional information: Method not found: 'Microsoft.FSharp.Collections.FSharpList`1<System.String> MyLib.Extensions.Extension1.ext1Method1(System.String)'.
Thanks in advance for your help.
I'm posting a succinct answer here even though the link provided by ildjarn answers the question: to fix the problem, ensure that the Nuget packages in the two solutions are the same.
In my case, the library used a slightly older version of FSharp.Core. Since I had the freedom to recompile the library against any version of FSharp.Core, I chose to update all the Nuget packages in both the library and the consumer. I did this by right-clicking the library solution, choosing Manage Nuget Packages for Solution... and making sure all of the packages were up-to-date.
WHen doing a PIP build it will copy in the solutions other projects outputs from the DeployList.xml but for a different project outside of this solution I only copied in the dll. However it does not like this and throws an error:
Ignored C:\Test.dll because it cannot be loaded properly due to:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) Source: Slb.Ocean.Core
I have also included other files and it copies them in just fine. It just seems to have an issue with dll's and exe's.
If the .dll you are trying to add is a native DLL (without a managed header), the PluginPackager displays the warning message you have given, like this one when trying to add Inventor.dll:
Ignored D:\Program Files\Schlumberger\Petrel 2012\Extensions\OceanLab\Inventor.dll because it cannot be loaded properly due to:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source: Slb.Ocean.Core
[though you would never need to include any .dlls that are part of Petrel, this is just an example]
However, these messages do not keep the .PIP from building, nor do they keep the referenced native .dlls from being included in the generated .PIP file.
There is a enhancement requirement recorded to clean up these misleading messages.
I am trying to register a .dll file but I am getting an error. The .dll is in the SysWOW64 folder, through the command line I then cd \Windows\SysWOW64 and run the following command regsvr32 php_sdo.dll
I then get the following error:
"The module "php_sdo.dll" failed to load.
Make sure the binary is stored at the specified path of debug it to check for problems with the binary or dependent.DLL files.
The specified module could not be found"
This kind of failure often occurs when one of the dependency of the DLL one wants to register (which physically means, that the program that attempts to register the DLL internally calls LoadLibrary) is missing. You can have a look at the dependency (tree) of your DLL using Dependency Walker.
I've recreated the Northwind Spring/NHibernate example that comes with Spring.NET, but with MySQL rather than SQLServer. I've almost got it working I think, but I'm getting this when I try to use Hibernate to load something from the database
A first chance exception of type 'System.IO.FileNotFoundException'
occurred in mscorlib.dll NHibernate.Util.ReflectHelper:
ERROR lambda_method - Could not load type
MySql.Data.MySqlClient.MySqlCommand, MySql.Data.
System.IO.FileNotFoundException: Could not load file or assembly
'MySql.Data' or one of its dependencies.
The system cannot find the file specified.
File name: 'MySql.Data'
Every project (DAO, Service, Web) has a reference to the MySQL.Data DLL so I'm a bit unsure what's going on.
Can anyone help me please?
Make sure that MySQL.Data.dll actually got copied to the output folder. And that you are using right platform (x32 vs x64 bit) and right version of .NET (2,3,3.5 vs 4). If everyhing seems fine, enable Fusion Logging and take a look at this article:
For FileNotFoundException: At the bottom of the log will be the paths
that Fusion tried probing for this assembly. If this was a load by
path (as in Assembly.LoadFrom()), there will be just one path, and
your assembly will need to be there to be found. Otherwise, your
assembly will need to be on one of the probing paths listed or in the
GAC if it's to be found.
You may also get this exception if an unmanaged dependency or internal
module of the assembly failed to load. Try running depends.exe on the
file to verify that unmanaged dependencies can be loaded. Note that if
you re using ASP.NET, the PATH environment variable it's using may
differ from the one the command line uses. If all of them could be
loaded, try ildasm.exe on the file, double-click on "MANIFEST" and
look for ".file" entries. Each of those files will need to be in the
same directory as the manifest-containing file.