vendredi 23 avril 2010 15:23
I want to deploy applications that use Private Deployment for SQL Server Compact 3.5 SP2 for Windows Mobile.
I made test sample according to SQL Server Compact 3.5 Service Pack 2 Books Online instructions.
I tested with WM 6.5 device and emulator.
I deploy to application folder on WM the following files:
C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices\System.Data.SqlServerCe.dll
C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices\wce500\armv4i\sqlceme35.dll
C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices\wce500\armv4i\sqlceqp35.dll
C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices\wce500\armv4i\sqlcese35.dll
The code is simple:
using (SqlCeConnection sqlCeConnection = new SqlCeConnection())
button1.Text = sqlCeConnection.ServerVersion;
When I run my test on clean WM 6.5(with SSCE 3.1 in ROM), it's ok. Server version is 3.5.8080.0.
When I run my test on WM 6.5 with SSC 3.5 SP1 installed, test fails with the error:
The application is trying to load native components of version 5386 that are incompatible with ADO.NET provider of version 8080.
Incompatible versions can lead to application instability and hence loading of SQL Server Compact has been aborted.
Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details.
Can anyone help me out with this?
- Modifié vv.iwork lundi 26 avril 2010 09:19
Toutes les réponses
samedi 24 avril 2010 12:24ModérateurAnd all the files you deploy are in the application directory, and have version 3.5.8080.0 ?
http://erikej.blogspot.com Erik Ejlskov Jensen - Please mark as answer, if this was it.
lundi 26 avril 2010 09:14Hi Erik,
I verified my test.
Yes, all the files I deploy are in the application directory on WM storage card, and have version 3.5.8080.0.
Actually I installed SSC 3.5 (3.5.5386). In thread's caption I wrote about SSC 3.5 SP1(3.5.5692). Sorry about that.
The proper thread's caption should be:
SSC 3.5 SP2 (3.5.8080) Private Deployment issue on Windows Mobile with SSC 3.5 (3.5.5386) installed
1) WM 6.5 / SSC 3.5 (3.5.5386) installed
2) WM 6.5 / SSC 3.1 (3.0.5300) installed
3) WM 6.5 / SSC 3.5 SP1 (3.5.5692) installed
4) WM 6.5 / SSC 3.5 SP2 (3.5.8080) installed
mardi 27 avril 2010 16:44Modérateur
This is expected behaviour as you are using SQLCE 3.5 SP1, so your application will be compiled with 18.104.22.168 version of System.Data.SqlServerCe.dll whereas SQLCE 3.5 RTM only installs 22.214.171.124 version of System.Data.SqlServerCe.dll. So the System.Data.SqlServerCe is being loaded from the private folder whereas other components are being loaded from central location which result in version mismatch problem.
If you really want to use RTM, SP1, SP2 releases of SQLCE with your application you must compile your app with 126.96.36.199 version of System.Data.SqlServerCe.dll.
Please mark this post as answers if it solves your problem.
mercredi 28 avril 2010 07:09Hi Tarun,
Totally disagree with you about expected behaviour.
I'm using PRIVATE DEPLOYMENT scheme for SSC 3.5 SP2.
This means that all required SSC files are placed in the application folder and I do not care what SSC version is installed (Central Deployment via cab) on WM.
I guess that I found a bug. And this bug is easy to reproduce.
lundi 3 mai 2010 06:16
Can anybody reproduce this issue?
Any help would be appreciated.
mercredi 12 mai 2010 11:36
I guess I found the confirmation of my problem...
Troubleshooting: Access Violation exception while using SQL Server Compact database with ADO.NET provider
There are two known issues related to the usage of SQL Server Compact provider which may lead to this Access Violation exception:
1. Version Mismatch [3.5 RTM and 3.5 SP1]:
Access Violation occurs when the loader loads different versions of Managed and Native SQL Server Compact 3.5 DLLs. This issue arises when different versions are available in the box and this happens with Private and Central deployment of SQL Server Compact 3.5.
To be specific, if SQL Server Compact 3.5 RTM is pre-installed [centrally deployed] in the box and application built on top of SQL Server Compact 3.5 SP1 privately deploys the SQL Server Compact DLLs.
In this case, the managed DLL [System.Data.SqlServerCe.dll v3.5.5692.0] will be loaded from private directory but the native DLLs [sqlceme35.dll, sqlceqp35.dll, etc. v3.5.5386.0] might get loaded from the central deployed directory.
IMHO this totally breaks the idea of Private Deployment (XCOPY) :(
If above is true, I see no arguments to use Private Deployment on WM, as I need to control what SSC version is installed centrally.
Can anyone comment this?
dimanche 16 mai 2010 18:47
I am having a similar problem. Did you ever find a solution to this?
lundi 17 mai 2010 07:09
I did not find solution for this.
And no feedback from community :(
IMHO Private Deployment (XCOPY) does not work for WM (as you depend on Central Deployment)
"native DLLs might get loaded from the central deployed directory" - this stops the show...
jeudi 18 novembre 2010 19:36
Go Path: C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices\wce500\armv4i
paste in dispositive mobile with Windows Mobile Device Center
run with emulator
mercredi 22 février 2012 08:34
In fact, altough the 3.5 SP2 files are installed on the desktop, the files deployed on the ce devices are still the old ones.
1) check when you deploy your solution from where the files are deployed (for exemple : C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices)
2) see in this folder (C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Devices) if the files are dated from 2010, if not you have the old files. find in your disk where the new files are located and copy them to :
3) it works ! (i just did that on a computer of a collegue).
By the way, if you install SP2, it will tell you either that it s already installed or that an earlier version is already installed.