Unable to connect to SQlite using mono - c#

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.

Related

Running in VS2019 Admin Cmd window -- gacutil.exe error: "Failure adding assembly to the cache. The system cannot find the file specified."

Running in VS2019 Admin Cmd window -- gacutil.exe error: "Failure adding assembly to the cache. The system cannot find the file specified."
GAC util path: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\gacutil.exe
Command line: gacutil.exe -i "DuraSysOrdFuncs.dll" -r FILEPATH "C:\Windows\DuraSysOrdFuncs.dll" ""
I picked this version of GACUtil just because the C# library was built with a target framework of .Net 4.7. It isn't clear to me that it much matters.
Doesn't matter what I put in the 3rd parameter of -r. Doesn't matter where I put my assembly on my local disk. Same error message.
I'm trying to put this in GAC because I need to call it from an SSIS package running on SQL Server 2016. I have opened Sysinternals ProcMon per a suggestion of #HansPassant in a different post. Not familiar with tool so haven't found the file location error. . . if that is the actual issue.
Any input much appreciated
The answer, as the commenters noted, and as ProcMon indicates, is to just include the path for the .net assembly you're registering: gacutil.exe -i "C:\YourAssemblyFileLocation\YourDLL.Dll" That's all it takes. . .you don't normally need -r parameters, etc. Thanks!
You can use powershell to register assemblies into GAC. It doesn't need any specific installation.
Set-location "C:\Temp"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Temp\myGacLibrary.dll")
If you need to get the name and PublicKeyToken, refer How do I find the PublicKeyToken for a particular dll?

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()

Is it possible to run Kinect V2 inside a Docker container?

I'm exploring the feasibility of running a C# Kinect Visual Gesture Program (something like Continuous Gesture Basics project https://github.com/angelaHillier/ContinuousGestureBasics-WPF) inside of a Docker for Windows container.
Is this even theoretically possible (run C# Kinect in a Docker for Windows container?)
If the answer to 1 is yes, here are some extra details:
I'm using the microsoft/dotnet-framework:4.7 image as a basis and my initial Dockerfile looks like this:
FROM microsoft/dotnet-framework:4.7
ADD . /home/gesture
WORKDIR /home/gesture
Build the image:
$ docker build -t kinect .
Turn on container:
$ docker run -dit --name kinectContainer kinect
Attach to a powershell session to monkey around:
$ docker exec -it kinectContainer powershell
When I attempt to run my gesture application from the Docker container I get the following error (which is expected since no Kinect SDK was installed in the container):
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'Microsoft.Kinect, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependenc
ies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatExcep
tion: Cannot load a reference assembly for execution. erable program. Check the spelling of the name, or if a path was included, verify that the path
--- End of inner exception stack trace ---
at GestureDetector.GestureDetectorApp..ctor()
At this point, the big question is how to install the Kinect v2 SDK [KinectSDK-v2.0_1409-Setup.exe] or the Kinect v2 runtime [KinectRuntime-v2.0_1409-Setup.exe] in the container.
The installers have a EULA and according to some clever University of Wisconsin folks, there is a technique to to extract installers using Wix's dark.exe decompiler(https://social.msdn.microsoft.com/Forums/en-US/a5b04520-e437-48e3-ba22-e2cdb46b4d62/silent-install-installation-instructions?forum=kinectsdk)
ex.
$ & 'C:\Program Files (x86)\WiX Toolset v3.11\bin\dark.exe' C:\installerwork\KinectRuntime-v2.0_1409-Setup.exe -x c:\installerwork\kinect_sdk_installersfiles
The issue I ran into when I got to the underlying msi files is there is no option to run them silently using msiexec.
I've figured out that the runtime installer (Runtime installer (KinectRuntime-x64.msi) extracted from the Kinect v2 SDK) makes at least the following changes in the filesystem:
Creates a folder "Kinect" in C:\Windows\System32 and adds 3 files to System 32:
k4wcll.dll
kinect20.dll
microsoft._kinect.dll
The last three files in System32 should be the 64-bit versions (the installer appears to have x86 and x64 versions of those 3)
Replicating those changes by hand does not lead to success on the host machine let alone in the container.
It's currently unclear what other registry/system changes are occurring with the installer (and whether or not that would get us over the goal line in the Docker container)
Any ideas about how to proceed from here?
In short no. docker on windows does not have the ability to hardware tunnel/map. on Linux, it does via the --device= option
As #VonC has stated you will need to use a Windows VM this could be Hyper-V or you can use Virtual Box then you can provide the Kinect Hardware via the Tunneling method (add/connect device), without this there would be no way for your container be that VM or not to access the hardware of the host machine with windows.
Another approach would be to try and install Kinetic in a Windows server VM, and detect the exact changes brought by said installation.
See for instance "How can I find out what modifications a program’s installer makes?" and a tool like ZSoft Uninstaller 2.5.
Once you have determined exactly what files/registry/variables are impacted by the installation process, you can replicate that in a Dockerfile.

Hadoop Streaming, C#, & Azure with External Libraries

I'm using Hadoop Streaming to run a mapreduce job in C# on a Linux cluster in Azure. However, I need to use the MathNet.Numerics library. I grabbed the dll using the NuGet package manager then included the dll as a reference file and in a lib folder as well as ensured that the build action is set to: Embedded Resource.
Whenever I try to run the following command:
hadoop jar ./hadoop-streaming-2.6.0.jar -input wasb:///CSV/ -output
wasb:///Output/reducer1.txt -file ./Mapper.exe -mapper Mapper.exe
-file ./Reducer.exe -reducer Reducer.exe
I get the following error in my output file:
System.IO.FileNotFoundException: Could not load file or assembly
'MathNet.Numerics, Version=3.11.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.
File name: 'MathNet.Numerics, Version=3.11.0.0, Culture=neutral, PublicKeyToken=null'
I've also tried to copy to MathNet.Numerics.dll to the cluster and include the file with a tag in the initial command:
hadoop jar ./hadoop-streaming-2.6.0.jar -input wasb:///CSV/ -output
wasb:///Output/reducer1.txt -file ./Mapper.exe -mapper Mapper.exe
-file ./Reducer.exe -reducer Reducer.exe -file ./MathNet.Numerics.dll
but had the same result.
On windows in VS 2014+
-Right click on "references", in the solution explorer.
-Select: Manage NuGet Packages
Click Browse, then type in the library your trying to install, it should grab everything you need including dependencies.
On Linux with Mono:
-https://docs.nuget.org/contribute/setting-up-the-nuget-development-environment
-Scroll down to the Linux install instructions
I have not used NuGet on Mono, but I assume it should work exactly the same way. I would at least try it to see if you're simply missing a dependency somewhere, as it should auto-magically get them for you.

Could not load file or assembly 'LinqToExcel, Version

I am trying to read an xlsx file.
I got exception that
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. c#
then I installed it from here
http://www.microsoft.com/en-us/download/details.aspx?id=13255
then I changed the platform target to x64
now i got this exception:
BadImageFormatException was unhandeled
{"Could not load file or assembly 'LinqToExcel, Version=1.9.0.0, Culture=neutral, PublicKeyToken=9c8ea65a58f03f1f' or one of its dependencies. An attempt was made to load a program with an incorrect format."}
Update 1
I already installed the linq_to_excel
using
Install-Package LinqToExcel
and then add the lib files to references
You have two options to solve
Enable IIS to run 32 bits app
Install LinqToExcel_x64
if change 32 bit app in iis From false to true,all conflicts about exteltolinq version solve
Please install Microsoft office in your machine it will automatically solve your problem. It worked for me as well.

Categories

Resources