using (var ctx = new TIS2APPContext())
{
var test = ctx.RSTOPs.ToArray();
}
I have just downloaded dotconnect for sqlite (trial version) and I have the above code. An exception "Method not found: 'System.String Devart.Data.SQLite.SQLiteConnectionStringBuilder.get_LicenseKey()'." is thrown when I run into ctx.RSTOPs.ToArray();.
May I know what I have done wrong? Thanks in advance.
With Target framework=.NET Framework, the first location CLR looks for the assembly is GAC. So, your development environment works with .NET Framework Devart.* assemblies although you installed .NET Standard Devart.* assemblies to the project via NuGet.
A solution is to reinstall dotConnect for SQLite in your development environment and select the "Do not install assemblies in the GAC" option in Setup Wizard. And, set the License Key parameter in your connection string.
Related
I'm trying to reference Oracle.DataAccess from a .NET 4.0 project, written on Visual Studio 2013. My machine's GAC has two versions of Oracle.DataAccess installed: 4.112.1.2 (provided by Oracle version 11gr2) and 4.121.2.0 (provided by Oracle version 12c).
I want to reference version 4.112.1.2 (my project must run with %ORACLE_HOME% set to 11gr2's install location, and referencing 4.121.2.0 causes runtime failures when this is the case). I do not have an admin account on my machine, so I can't just uninstall the 12c dll.
I have tried the following steps to force the executable to load the 4.112.1.2 dll at runtime:
Reference the dll in my .csproj file using the strong name:
<Reference Include="Oracle.DataAccess, Version=4.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86"/>
Updating my App.Config file to force a redirect:
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral"/>
<codeBase version="4.112.1.2" href="C:\Path\To\11gr2\Oracle.DataAccess.dll"/>
<bindingRedirect oldVersion="4.121.2.0" newVersion="4.112.1.2"/>
<publisherPolicy apply="no"/>
</dependentAssembly>
I modified my PATH to make the 11gr2 Client's bin directory first on my path:
set PATH="C:\path\to\11gr2\BIN;%PATH%"
No matter what I do, however, the executable loads the 4.121.2.0 dll from the GAC at runtime. Here's what it says when I attach a debugger:
'MyApp.exe' (Managed (4.0.30319)): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_32\Oracle.DataAccess\v4.0_4.121.2.0_89b483f429c47342\Oracle.DataAccess.dll'
I've read through Microsoft's documentation on assembly binding (here and here). I've also read the StackOverflow answers that seem to be related to my issue (here and here), but nothing has worked.
How do I force .NET to load the correct DLL version at runtime from the GAC?
EDIT:
Wernfried's answer leads me to think I may be looking at this the wrong way. Here's exactly what's happening:
I run my application with ORACLE_HOME=C:\ORACLE\ora12c, everything works as normal (database accesses succeed, application is happy)
I run my application with ORACLE_HOME=C:\ORACLE\ora11gr2 (the required version). Application crashes with following exception:
Oracle.DataAccess.Client.OracleException ORA-12557: TNS:protocol adapter not loadable.
<stacktrace follows>
Following the stacktrace, I discovered that the error occurred in the call my application made to create a database connection. I've checked my connection string and verified that it is correct (and that it is the same connection string that was succeeding with 12c). I then discovered that version of the Oracle.DataAccess dll I was calling was the 12c one, not the 11gr2 one. From this, I concluded that I needed to modify the call to load the dll to "force" the 11gr2 one. If I'm barking up the wrong tree, please let me know!
As far as I know, ODP.NET provider 4.112.1.2 works only with Oracle Client 11.2, resp. ODP.NET provider 4.121.2.0 requires Oracle 12.1 Client.
Do you have both versions of Oracle Client installed on your machine?
In order to use one or the other you must also set your PATH environment variable accordingly. PATH must include folder of Oracle client binaries you like to use in your application.
Note, the architectures (i.e. 32-bit vs. 64-bit) have to be all the same at your application, the Oracle Client and the ODP.NET provider.
But why do you like to force a particular version of ODP.NET? I recommend to use this reference
<Reference Include="Oracle.DataAccess">
<SpecificVersion>False</SpecificVersion>
<Private>False</Private>
</Reference>
then your application will load automatically the correct version of ODP.NET no matter what is installed on your machine (or the machine of your customer).
Anyway, in case you like to run test and force particular version of ODP.NET you can use dynamic binding. For this your code like this:
using (OracleConnection con = new OracleConnection(connString))
{
con.Open();
...
}
has to be re-written like this one:
var DLL = default(Assembly);
DLL = Assembly.LoadFrom(#"C:\Path\To\11gr2\Oracle.DataAccess.dll");
// resp for GAC:
// DLL = Assembly.Load(String.Format("Oracle.DataAccess, Version={0}.{1}.*.*, Culture=neutral, PublicKeyToken=89b483f429c47342", 1, 112));
var type = DLL.GetType("Oracle.DataAccess.Client.OracleConnection", true, false);
using ( dynamic con = Activator.CreateInstance(type, connString) ) {
con.Open();
...
}
I believe I have it fixed.
What got it working for me was to unset the ORACLE_HOME environment variable, and to put C:\Path\to\11gr2\bin at the beginning of my path, like so:
set PATH=C:\Path\to\11gr2\bin;%PATH%
After installing Npgsql and Simple.Data.PostgreSql from NuGet, and then using the following code:
var connectionString = ConfigurationManager.ConnectionStrings["runningJournal"].ConnectionString;
var db = Database.OpenConnection(connectionString);
var userId = db.user.Insert(userName: "foo").userId;
I get this exception:
System.TypeLoadExceptionCould not load type 'NpgsqlTypes.BitString'
from assembly 'Npgsql, Version=3.0.4.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7'.
at Simple.Data.PostgreSql.TypeMap..cctor()
I assume that this is an issue with Simple.Data.PostgreSql since accessing the database from Npgsql works just fine. Is this a bug, or is there some other dependency that I need to manually add? Perhaps something else?
Npgsql 2.x had an NpgsqlTypes.BitString type which was removed in 3.0, which uses .NET's built-in BitArray. It would seem that the version of Simple.Data.PostgreSql which you're using is compiled against Npgsql 2.x, but somehow you're using Npgsql 3.0 in your project. Make sure you're using Npgsql 2.2.7 and not 3.0.x, and perhaps let the Simple.Data.PostgreSql project know to release a new version which works with Npgsql 3.0.
I have an asp.net / C# web application running in a Windows environment.
The project builds fine and runs perfectly on my local machine's VB.net development server.
However, when I publish to the real application server I receive the following error message:
[OracleException (0x80004005): The provider is not compatible with the version of Oracle client]
[TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception.]
There is a version of this application currently up and running just fine, I am testing on the live server in a different directory. I even tried snagging the Oracle.DataAccess .dll from the working application but still get the same error message.
First off: The Oracle client/provider is a mess. And that goes for both the MS one (depreciated anyway) as well as the Oracle one.
In order to connect to an Oracle DB via the ODP.NET provider three things need to be setup properly:
Oracle client needs to be setup properly ( has nothing to do with the .NET provider, this referring to the installed oracle client usually in c:\oracle)
The ODP.NET provider needs to be compatible with the installed Oracle client
The architecture of client and provider and your application need to match, you cannot use the 64bit client with an x86 provider/application and vise versa
Usually the best is to have the newest version of both. But if you want to get rid of this issue once and for all use a third party oracle .NET provider.
UPDATE
One of the better ones is from DataDirect (no affiliation):
http://www.datadirect.com/products/net/net-for-oracle/index.html
It's not just installation (no oracle client necessary), but it's also faster, fully managed, x64 and general support is a way better than what you get with the ODP.NET one. It will cost you though.
The DevArt one is pretty decent as well (and much much cheaper):
http://www.devart.com/dotconnect/oracle/
We decided for the DataDirect for extensibility reasons, this should not be relevant to you however.
Here you can find a good compilation of third parties that build .NET providers, not limited to oracle though:
http://msdn.microsoft.com/en-us/data/dd363565
I came across the same scenario before
Reading this may help you some how ODAC Oracle for .NET
about your problem in your server you have to install the whole ODAC Client from oracle
the latest version now is 4.xx
i have installed it and everything works like charm
hope this helps :)
Take Care
I was able to solve this by searching for Oracle.DataAccess.dll on the prod server.
So instead of trying to build/deploy the project with the Oracle.DataAccess.dll from my development environment, I copied the .dll down from the prod server oracle client directory and included that as a reference instead. I also set the .dll properties "Copy Local = true" and "Specific Version" = true. So it looks like there is a mismatch between the oracle client version on my dev server and the prod server.
Equals, with Oracle.DataAccess.dll Works!!!!
//using Oracle.DataAccess.Client
object pdf = null;
var queryString =#"SELECT PDF FROM DIGITAL WHERE ID_DIGITAL=1001" ; //example
var ctx = new Entities();
var entityConn = ctx.Connection as EntityConnection;
if (entityConn != null)
{
var dbConn = entityConn.StoreConnection as OracleConnection;
dbConn.Open();
var cmd = new OracleCommand(queryString, dbConn);
using (var reader = cmd.ExecuteReader())
{
while (reader.Read())
{
pdf = reader[0];
}
}
dbConn.Close();
}
return pdf;
In addition to the other suggestions, just try running Visual Studio as administrator.
I spent a lot of time messing around with the GAC and various versions of the Oracle.DataAccess.dll, and in the end just running VS as administrator got it to run.
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.
I'm using Visual Studio 2008 Pro.
I'm probably missing something very obvious here, but I've been trying to get the CTP for Sql Server compact 4 to work in my asp.net mvc application. I can find next to no instruction on how to set this up or a working example application. My goal is a private install so I can just include it in my web app without having to do sql server setup on my domain hosting. This is really just me shooting the breeze and trying to figure this out. I don't plan to host a market or anything with this.
So, I've copied all the dll's that install in the base 4.0 direction (c:\Program Files\Sql Server compact\v4.0) to a lib folder in my application. I've set the copy to output direction option to 'Copy if Newer'. I then reference the System.Data.SqlServerCE dll and set 'Copy Local' to True.
I created an sdf file via Sql Studio Express. An important note is that I did not see an option for creating a CE 4.0 version of this file, so it was created using CE 3.5. I create a few tables, add a few rows to those tables, copy the *.sdf file to my App_Data directory. It's worth mentioning that, from inside VS 2008, this file never appears in my project, but it does exist in the physical location of the App_Data directory. I'm not sure why this is.
Next, I just try making a basic connection to my sdf file via:
SqlCeConnection conn = new SqlCeConnection("DataSource=rpg.sdf");
This yields the error below:
Unable to load the native components of SQL Server Compact corresponding to the ADO.NET provider of version 8402. Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details.
I figure from here, I'd just try getting Sql CE 3.5 to work. I upgrade my local installation of Sql CE 3.5 to sp2. I copy the dlls at the base location (c:\Program Files\Sql Server compact\v3.5), including removing and readding the version of the System.Data.SqlServerCE dll from my project references.
The curious thing here is when I right click and look at the properties of the referenced SqlServerCE dll, it always says it's version 4.0.0.1.
Guys, I really could use some direction here. I have searched stack overflow, the help docs, books online, and googled. I really haven't found anything that takes this from the very top for either CE 3.5 or 4.0 and tells me exactly what dll's to add, where to put them, how to reference them, how to add the .sdf file to my project, connect to it, and query from it. I did come across a few mentions of an IBuySpy portal sample app that was supposed to use Sql CE 3.5, but can't actually navigate the msdn download maze to get to it. Ideally, I want to setup a private deploy for CE 4.0.
I'm all ears. Suggestions, points, whatever would be highly appreciated. Thank you!
YES I DID SEE THE KB. IT DIDN'T HELP
See it here: http://support.microsoft.com/kb/974247
RESULTS FROM CORFLAG
Okay, tried that and these are my results:
C:\Development\Mvc2MessingAround\Mvc2MessingAround\bin\Lib>corflags System.Data.
SqlServerCe.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v2.0.50727
CLR Header: 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 1
I would have sworn I installed the x86 version of both versions of Sql CE (3.5/4). The installer might have gotten confused somehow because my processor is 64bit capable, but i'm running Windows xp sp 3 32 bit. The results seem to indicate it's 64 bit. Is that the case?
ADDED DETAILS
To date the configurations below have been tried on 2 machines. Both are Windows xp sp3 32 bit with a 64 bit capable processor. The development environment on both is VS 2008 Pro. The results on machine 2 come after a fresh install of the Sql CE 4 Ctp.
CONFIGURATION #1
myapp\bin\
System.Data.SqlServerCe.dll
myapp\bin\private
amd64
x86
myapp\bin\private\x86
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
myapp\bin\private\amd64
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
Error:
An exception of type 'System.Data.SqlServerCe.SqlCeException' occurred in System.Data.SqlServerCe.DLL but was not handled in user code
Additional information: Unable to load the native components of SQL Server Compact corresponding to the ADO.NET provider of version 8402. Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details.
Code:
SqlCeConnection conn = new SqlCeConnection();
CONFIGURATION 2
Same as #1, but with System.Data.SqlServerCE.Entity.dll at myapp\bin direction.
The page errors before hitting the code above. This is the message:
Could not load file or assembly 'System.Data.SqlServerCe.Entity' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'System.Data.SqlServerCe.Entity' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
I've checked the project settings in VS 2008 Pro and the .Net 3.5 framework is set as the target.
CONFIGURATION 3
Same as #1, except the System.Data.SqlServerCE.dll is referenced from the myapp\bin\private folder.
Results are the same as CONFIGURATION #1 (error message is 100% same and the error occurrs on the same line of code).
CORRECT CONFIGURATION
Per Erik's instructions (had I followed them more carefully), the setup should be
myapp\bin
x86
amd64
System.Data.SqlServerCE.dll
Reference the System.Data.SqlServerCE.dll directly from the bin folder for the code. My folly was thinking the Private folder needed to be included, but it doesn't. Do not put the System.Data.SqlServerCE.Entity.dll in the bin folder unless you are using a .net 4.0 solution. I don't think that dll works w/ 3.5.
Helpful link:
Link
SQL CE 3.5 does not work with ASP.NET, you must use 4.0 CTP.
Download from here.
Install the runtime.
Copy the following directory contents (including the x86 and amd64 folders) to the bin folder of your ASP.NET app:
C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private
UPDATE: Use System.Data.SqlServerCe.dll from the Desktop folder to avoid Medium Trust issues
myapp\bin\
System.Data.SqlServerCe.dll
myapp\bin\x86
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
myapp\bin\amd64
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceqp40.dll
sqlcese40.dll
Add a reference to the System.Data.SqlServerCe.dll file you just put in your /bin folder.
Place the SQL Compact sdf file in your App_Data folder.
Add connection string:
<connectionStrings>
<add name ="NorthWind"
connectionString="data source=|DataDirectory|\Nw40.sdf" />
</connectionStrings>
Connect! :-)
using System.Data.SqlServerCe;
protected void Page_Load(object sender, EventArgs e)
{
using (SqlCeConnection conn = new SqlCeConnection())
{
conn.ConnectionString = ConfigurationManager.ConnectionStrings["Northwind"].ConnectionString;
conn.Open();
using (SqlCeCommand cmd = new SqlCeCommand("SELECT TOP (1) [Category Name] FROM Categories", conn))
{
string valueFromDb = (string)cmd.ExecuteScalar();
Response.Write(string.Format("{0} Time {1}", valueFromDb, DateTime.Now.ToLongTimeString()));
}
}
}
If your using a connection string that uses a providerName and you haven't installed the SDK, then you also need to add this to you web.config (or app.config)
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Data.SqlServerCe" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
<bindingRedirect oldVersion="4.0.0.0-4.0.0.1" newVersion="4.0.0.1"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SqlServerCe.4.0"/>
<add name="Microsoft SQL Server Compact Data Provider 4.0" invariant="System.Data.SqlServerCe.4.0" description=".NET Framework Data Provider for Microsoft SQL Server Compact" type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=4.0.0.1, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
</DbProviderFactories>
</system.data>
NOTE: the "remove" is needed in case you installed the SDK, as that will put this info in your machine.config
OK, here's a guess, since you're fishing for them.
Run corflags.exe on the assembly you copied to your references directory. What type of machine are you building for? If you're on a 64-bit machine and you're compiling to x64 or anyCpu, make sure that corflags tells you that your references are not 32-bit only references. Maybe it's "falling back" to an the wrong version in your GAC or something. If it tells you that the referenced assembly is 32-bit only, either compile your project as a 32-bit project or find a 64-bit version of the DLL?
If you are installing the SQL CE provider using NuGet, the simplest solution is to add a post-build step to copy these from the NuGet package NativeBinaries folder
The key for me was realizing that the version of System.Data.SqlServerCe.Entity.dll in the Private directory (C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private) is 4.0.0.1, where the version beneath the Desktop directory (C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Desktop\System.Data.SqlServerCe.Entity) is 4.0.0.0. The version of System.Data.SqlServerCe.dll in the Private directory is 4.0.0.0.
I think it was a mistake on the part of Microsoft to distribute an updated SqlServerCe.Entity.dll without a corresponding update to SqlServer.dll.
I build an asp.net web api and hosted it on azure and faced some issues with sql server compact I fix it by:
first remove all system.data.sqlserverce.dll and any dll use it then
installed these tow packages :
Install-Package SqlServerCompact then rebuild
Install-Package EntityFramework.SqlServerCompact -Version 4.3.6 then rebuild
after I did it just worked fine for me + install any NuGet package that depends on system.data.sqlserverce.dll they all just work great
I hope this will help some one
reference