We use SQLite in-memory databases in our dotnet codebase for integration testing our repository layer with ORMLite. When I try to run a test on Mac I get this error:
System.DllNotFoundException
Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libSQLite.Interop.dll, 0x0001): tried: 'libSQLite.Interop.dll' (no such file), '/usr/local/lib/libSQLite.Interop.dll' (no such file), '/usr/lib/libSQLite.Interop.dll' (no such file), '/Users/aaron/Projects/joinder/DASH/Test/ClientSiteData.Tests/bin/Debug/net6.0/libSQLite.Interop.dll' (no such file)
at System.Data.SQLite.UnsafeNativeMethods.sqlite3_config_none(SQLiteConfigOpsEnum op)
Is there a way to get this working on Mac so I don't have to revert to my Windows machine every time I need to run tests?
Can you try installing one of the other OrmLite.SQLite packages, e.g. to use the Microsoft.Data.Sqlite ADO.NET Provider use:
<PackageReference Include="ServiceStack.OrmLite.Sqlite.Data" Version="6.*" />
Related
I am attempting to build and use the MicoCharts project available here: https://github.com/dotnet-ad/Microcharts which is dependant on this SkiaSharp project available here: https://github.com/mono/SkiaSharp
The specific version I am attempting to use is 15.9.1 (the version that the nuget package downloads) which utilizes skia m59.
I need to build them myself and cannot use Nuget due to business restrictions, just use the package isn't an option for me.
I have built skia m59, SkiaSharp and MicroCharts but when I attempt to create a SKBitmap object I get an error when it attempts to initialize SkiaSharp.SKImageInfo. The error is as follows:
Unable to find an entry point named 'sk_color_get_bit_shift' in DLL 'libSkiaSharp'.
I had to make a few changes to the base BUILD.gn to point to the correct file locations, for the windows SDK and the VC install. I enabled skia_use_gdi in the BUILD.gn and ran the following commands.
python2 tools/git-sync-deps
gn gen out/Release --args="is_debug=false is_official_build=true skia_use_system_expat=false skia_use_system_libjpeg_turbo=false skia_use_system_libpng=false skia_use_system_libwebp=false skia_use_system_zlib=false skia_use_icu=false is_component_build=true"
ninja -C out/Release skia
This process outputs a DLL I assumed is the same as the libSkiaSharp that the SkiaSharp project relies on. I add all my references and run, the project runs successfully until I attempt to create the SkBitmap object then it fails.
Either this DLL is not the correct DLL and I am misunderstanding something here or something in my process is wrong. I would love any help I can get as I am completely new to building these sorts of projects, I am a C# developer by trade.
This is not the same thing. SkiaSharp has a few other bits that it adds to the core skia. The output that you would have got is a skia.dll, which only part. Not sure how you got a libSkiaSharp from the skia target...
If you can't use SkiaSharp from NuGet.org (which is the supported case) you can follow this to build your own: https://github.com/mono/SkiaSharp/wiki/Building-SkiaSharp
You can also check out the Azure DevOps yaml: https://github.com/mono/SkiaSharp/blob/master/scripts/azure-pipelines.yml
Just set up your own DevOps job to use that and all the work will be done for you.
I'm using VS Express 2013 .Net 4.5. I'm designing in MVC5 and EF6 with MS SQLServer LocalDB in an Oracle VirtualBox Windows 7 64bit client.
I am trying to apply SQL Server LocalDb migrations with the command:
PM> Enable-Migrations -ContextTypeName SGHWA_MVC.Models.Context
This always fails.
My limited web knowledge is with Web Forms so I am completely new to MVC and EF. Also I have never used PMC and Powershell. I have searched for solutions but have not found questions similar to this error that Package Manager Console produces.
First there is a warning:-
Cannot determine a valid start-up project. Using project 'SGHWA_MVC' instead. Your configuration file and working directory may not be set as expected. Use the -StartUpProjectName parameter to set one explicitly. Use the -Verbose switch for more information.
PCM drop-down box shows the Default project correctly as SGHWA_MVC. The solution property pages show this one project as the start-up project.
I went to http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference but could not see the -StartUpProjectName parameter mentioned. I'm not sure to which command this parameter applies.
Then the first error appears:-
Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'file://\W7O2007\Users\Admin\Documents\Visual Studio 2013\Projects\SGHWA_MVC\packages\EntityFramework.6.1.0\tools\EntityFramework.PowerShell.Utility.dll' or one of its dependencies. Operation is not supported.
(Exception from HRESULT: 0x80131515)"At \W7O2007\Users\Admin\Documents\Visual Studio 2013\Projects\SGHWA_MVC\packages\EntityFramework.6.1.0\tools\EntityFramework.psm1:780 char:62
+ $utilityAssembly = [System.Reflection.Assembly]::LoadFrom <<<< ((Join-Path $ToolsPath EntityFramework.PowerShell.Utility.dll))
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
It suggests the file is not there to be loaded but it does exist on the PC at the path shown. I suspect it is the Join-Path that fails but am unsure how to test this.
The packages.config files has a line:-
(leading < removed) package id="Powershell.Deployment" version="1.1.0.0" targetFramework="net45" />
My research shows it could be permissions, remote access, that the Project Build should have Generate Serialization Assembly as 'On', 'Off' or 'Auto' or even NuGet packages that cause this but I cannot determine if it is a PMC, NuGet, Powershell or Windows problem.
Two more error messages appear relating to similar problems in EntityFramework.psm1 and seem to be related to this first problem.
Please can anyone advise the likely cause and guide me through what/how to test and solve this?
I realize this is an old thread, but I just ran into this problem using a newly-installed copy of Microsoft Visual Studio 2015 Enterprise with Update 1.
My solution was to delete this folder:
C:\Users\\(my user ID)\\.nuget\packages\EntityFramework\6.1.3
and allow it to be regenerated the next time the Entity Framework is added to a project. Originally, the PowerShell DLL's were missing from this folder. Strange.
Your question has several parts.
First, you cannot find the documentation, and you have it at your fingertips:
Update-Database -?
Then, you can read at the bottom of this help:
TO see the examples, type: "get-help Update-Database -examples".
For more information, type: "get-help Update-Database -detailed".
For technical information, type: "get-help Update-Database -full".
Second, -StartupProjectName is required to find the configuration file that has the required connection string (you also specify the connection directly using another options) NOTE: This has nothing to do with the solution's startup project
And, if having this clear doesn't solve the problem, try uninstalling and reinstalling the EntityFramework package (in case something went wrong). Take into account that, if you have several projects, it's possible that you need to do this for all the affected projects. You can do this more easily using the Manage Nuget Packages for Solution... menu option.
Edit
(Added to help choose the right Default project in Package Manager Console or specify -ProjectName).
I forgot to answer the most important part of the question: for Migrations commands to work, it's necessary to run them on a project that references the EF assemblies. This solves the missing assembly problem.
In this case it's clear that the chosen StartUpProject, which is the Web App have the connection strings, but doesn't have a reference to EF. That's why running the command fails. And most probably the command is being run with this as the default project in the console.
To solve this, you need to run Migrations within a project which has references to EF, and it will work flawlessly: choose that project in the drop down list named "Default project" on the top bar of the Package Manager Console.
This can also be done by specifying the -ProjectName option, which must point to the project containing the Migration configuration class, and thus, have also the reference to EF. NOTE: you must also sepcify the -ConfigurationTypeName param if you have several migrations for several contexts, as supported from EF 6.
I am trying to create a WCF service to host in IIS.
My production and development servers are 64 bit.
The WCF service needs to be able to connect to a several different Oracle databases based on the client request.
I am using Entity Framework 5 with ODAC, and with the DbContext Initialiser, I have the option of providing a database connection to use.
private void ExampleSelect(string dataSource, string user, string password)
{
var connection =
string.Format("DATA SOURCE={0};PASSWORD={1};USER ID={2}",
dataSource, password, user);
using (var context = new OracleDbContext(new OracleConnection(connection)))
{
// do stuff here
}
}
The problem I have lies with new OracleConnection(connection). To use this line, I need to reference the x64 version of Oracle.DataAccess.dll
When I come to publish, I get the warning:
and the error:
The platform target for my project is currently 'Any CPU'. If I change this to target x64, I get the same error, but this time it refers to my project and not Oracle.DataAccess
Any of the above builds successfully on my development machine, I only get the errors when I come to publish.
What am I doing wrong here?
These solutions appear to be related, but they all refer to 32 bit Oracle Dlls:
Could not load file or assembly Oracle.DataAccess
Could not load file or assembly 'Oracle.DataAccess' 64 bit ODP.NET
Could not load file or assembly 'Oracle.DataAccess error
To rule it out, I have also tried installing both the 64bit and 32bit Oracle Clients on the development server, but I still don't get as far as even publishing so I'm not sure that the server is the cause of the problem.
The Enable 32 bit Application property on the Application pool in IIS does not make any difference, but I tried it anyway.
To eliminate your problem you must meet the following conditions. Since you want everything run in x64:
1.Make sure that you have installed 64-bit Oracle client software
2.Make sure that you using 64-bit Oracle.DataAccess.dll (use corflags to verify)
3.Make sure you build your application with x64 configuration
4.Disable Enable 32 bit Application on IIS pool
This is a common mistake by many people. They install 32-bit client and try to run x64 Oracle.DataAccess
Currently I am struggeling with some unit tests that run fine from within visual studio but fail in Teamcity
I tracked down the problem to mstests.exe
Let's say I do the following steps:
Create a new Test project
Add a new Test class with the following test
[TestMethod]
public void TestCanCreateSqLiteConnection()
{
// Create the DbProviderFactory
var factory = DbProviderFactories.GetFactory("System.Data.SQLite");
// Create the DbConnection.
var connection = factory.CreateConnection();
// Assign connection string
connection.ConnectionString = "Data Source=database.sqlite";
// check the result
Assert.IsTrue(connection.GetType().Name.Equals("SQLiteConnection"));
}
Add an app.config file and add this:
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SQLite" />
<add name="SQLite Data Provider"
invariant="System.Data.SQLite"
description=".Net Framework Data Provider for SQLite"
type="System.Data.SQLite.SQLiteFactory, System.Data.SQLite" />
</DbProviderFactories>
</system.data>
Install "System.Data.SQLite (x86/x64)" via nuget
Run test from Visual Studio (2010). It should run fine:
Now I want to run the same test via mstest.exe so I:
Open a Visual Studio 2010 command prompt
Navigate to the bin\debug folder
Execute
mstest.exe /testcontainer:TestProject1.dll /detail:errormessage
The test eventually failes with
System.DllNotFoundException: Unable to load DLL 'SQLite.Interop.DLL':
The specified module could not be found. (Exception from HRESULT:0x8007007E)
Now if I extend the call to mstest.exe with testsettings the test runs fine.
mstest.exe /testcontainer:TestProject1.dll /detail:errormessage
testsettings:..\..\..\Local.testsettings
The Local.testsettings contains nothing special, even if I create a new testsettings file and use this, the test passes.
<?xml version="1.0" encoding="UTF-8"?>
<TestSettings id="fc837936-41d1-4987-8526-34f9336569f5" name="TestSettings1" enableDefaultDataCollectors="false" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>default test run</Description>
<Deployment enabled="false"/>
</TestSettings>
So the main question is, why this has an impact on my test run, and how I can run my tests form commandline without specifying a *.testsettings file.
You need to use a DeploymentItem to ensure the file is copied to the deployment directory when testing via the command line. I created a base class for all of my test classes that depend on the SQLite database.
[TestClass]
[DeploymentItem("Resources\\empty-db.sqlite", "Resources")]
[DeploymentItem("x64\\SQLite.Interop.dll", "x64")]
[DeploymentItem("x86\\SQLite.Interop.dll", "x86")]
public class SQLiteTest
{
[TestInitialize()]
public void ClearDatabase()
{
File.Copy("Resources\\empty-db.sqlite", "test-db.sqlite", true);
}
}
I encountered a similar error message a while back. If I remember correctly, the following was the crux of the issue: (it may not be 100% relevant for the OP, but it might be useful to somebody who hits this down the line).
The problem was that my unit tests all failed in Release mode with an exception complaining about the availability (or lack thereof) of the SQLite.Interop.dll. I realised that when built in Debug mode, the bin\Debug folder had 2 sub folders (x64 and x86) each with a copy of SQLite.Interop.dll but, in Release mode these files/folders did not exist.
To resolve it, I created the x64 and x86 folders in my project and added the appropriate version of SQLite.Interop.dll too them, setting the Copy to ouput setting to Copy if newer. (I had originally used 'Copy always' but it seems the MS Test engine doesn't shut down when the test run is complete - which can lock the file. Since the dll shouldn't change regularly the Copy if newer option was a suitable approach).
This enabled my unit tests to pass in release mode - but unfortunately (as in the OP's case) they did not work when run from the command line. Still trying to figure that one out - I think it's because MSTest is 32-bit and SQLite uses native code which is (maybe) 64-bit but the finer detail necessary to resolve this eludes me at present.
Two year later and it is still a pain to get SQLite working in unit tests.
Yesterday I included the current SQLite nuget package into a unit test project with <Deployment enabled="true"/> enabled and could not access sqlite by the dbproviderfactories method.
I included the SQLite interop directories with
<Deployment>
<DeploymentItem filename="packages\System.Data.SQLite.Core.1.0.98.1\build\net40\" />
</Deployment>
But that was not enough. Accessing the provider with
DbProviderFactories.GetFactory("System.Data.SQLite");
still threw an error Failed to find or load the registered .Net Data Provider error unless I made this call var factory = new System.Data.SQLite.SQLiteFactory(); After that I could acces SQLite witht the DbProviderFactories.
I included this in the ClassInitialize method so is is only executed once.
I've encountered a similar issue where the tests run through fine in Visual Studio 2013 but if run directly by MSTest many would fail. No SQL Lite used!
In the end I just added a default .testsettings file to the MSTest call and now the results are consistant.
Is there a way to make a simple installer that includes the necessary runtimes and dependency packages, and creates an icon in the OpenSuse menu, so the application will "just work?"
The actual application is just an executable (.EXE) and a handful of support files (mostly XML and CSV).
I already have the application successfully building and executing in MonoDevelop 2.0.
I originally tried to install the Mono Runtime via zypper from the following repository http://ftp.novell.com/pub/mono/download-stable/openSUSE_11.0, but quickly got bogged down in missing package dependencies.
This is what happens when I try to use zypper to install the Mono runtime:
linux-lkfu:~ # zypper addrepo http://ftp.novell.com/pub/mono/download-stable/SLE_11 mono-stable
Adding repository 'mono-stable' [done]
Repository 'mono-stable' successfully added
Enabled: Yes
Autorefresh: No
URI: http://ftp.novell.com/pub/mono/download-stable/SLE_11
linux-lkfu:~ # zypper refresh --repo mono-stable
Retrieving repository 'mono-stable' metadata [done]
Building repository 'mono-stable' cache [done]
Specified repositories have been refreshed.
linux-lkfu:~ # zypper dist-upgrade --repo mono-stable
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Nothing to do.
linux-lkfu:~ #
Notice the last line before the prompt that says "Nothing to do." I don't think it's doing anything.
One option is to buy mono support for SLES 11 from Novell. That will grant you a tested, supported and working mono repository.
If not you have to use the SLES repositories. For mono it's http://ftp.novell.com/pub/mono/download-stable/SLE_11
This should do it:
zypper addrepo http://ftp.novell.com/pub/mono/download-stable/SLE_11 mono-stable
zypper refresh --repo mono-stable
zypper dist-upgrade --repo mono-stable
If you have Visual Studio, you can try Mono Tools for Visual Studio, which provides tooling to make this easy. It is fully functional for 30 days.
http://go-mono.com/monotools/
that depends on how you plan to package them up. Either you manually create (deb for Debian and Ubuntu, rpm for Fedora and openSUSE, or anything else).
Personally, I think at first it is acceptable to simply add a .sh to your ZIP package and ask the end users to execute it for dependency checking, installing, and so on.
Then you can learn about the packaging methods.