SQL Server Compact Edition Versioning Issue

Question

Hello:

We are creating a query tool which will ship with the new SQL Server Parallel Data Warehouse and are having versioning issue with SQL Server Compact Edition in our tool.

We are installing SQL Server Compact Edition Locally.  On 32-bit computers we are putting the assemblies in our program files directory.  On 64-bit computers we are installing both 32-bit and 64-bit assemblies in our program files directory inside of AMD64 and X86 folders.

We had SQL Server Compact Edition 3.5 SP1 installed.  A user at Microsoft who is helping us test our product with their data warehouse has SQL Server Compact Editoin 3.5 SP2 installed and were receiving the following error.

Error:  Unable to load the native component of SQL Server Compact corresponding to the ADO.NET provider of version 8080.  Install the correct version of SQL Server Compact.  Refer to KB article 974247 for more details.

We have read the KB and followed the guidance by installing both version of SQL Server Compact Edition for 64-bit computers (locally).

Since SQL Server Compact 3.5 SP2 was available we decided to upgrade.  Now we are receiving the following error for another person at Microsoft who we believe to have SQL Server 3.5 SP1 installed on their computer.

Error:  File version mismatch detected between ADO.NET Provider and native binaries of SQL Server Compact which could result in an incorrect functionality.  This could be due to the presence of multiple instances of SQL Server Compact of different versions.  Please install SQL Server Compact binaries of matching version [ADO.NET Provider File Version = 3.5.5692.*, Native Binary File Version = 3.5.8080.*]

Can anything be done in future releases of SQL Server CE to get all these different versions of SQL Server Comact playing together nicely?

I've tested out our build which installs CE 3.5 SP2 with only SQL Server CE 3.5 SP1 installed on my computer on Windows 7 64-bit and our program runs fine.  I installed CE 3.5 SP1 using the MS installer.  SQL Server 3.5 SP2 was not installed also.

I've verified that SQL Server CE 3.5 assemblies (version 3.5.5692) are installed on the user's computer who is having issues.  There is no reference to SQL Server Compact Edition in their Add/Remove programs so I'm assuming a  program such as Office installed these assemblies.  When they try to run our program they get a version mismatch issue.

Answer 1

From the explanation, I see that you are trying to work in PD (Private Deployment) mode with SQL Server Compact, but you are running into issues when there is another SP of SQL Server Compact available centrally. Can you double check the System.Data.SqlServerCe.dll you are shipping is picked up from %Program Files%\Microsoft SQL Server Compact Edition\v3.5\Private folder?

---

“This posting is provided "AS IS" with no warranties, and confers no rights”.

Answer 2

Hello Imran:

Yes, we are doing a private deployment...

It looks like this private folder was added in 3.5 SP2?  We were using the Desktop folder for some reason (not sure why...).

We're now referencing System.Data.SqlServerCe.dll from this private folder in our project.

However,  the setup project is automatically picking this as a detected dependency and it is referencing the version in the GAC.  Is this okay or do we need to exclude this file and reference the dll from the private folder in our Setup project.

Thanks for your help.  If we can get this issue resolved we will be very happy!

Answer 3

Hello Imran:

We have another issue with versioning.  We created a .SDF file with SQL Server Compact 3.5 SP1 referencing the System.Data.SqlServerCe.dll in the Desktop folder.

Now that we have upgraded to SQL Server CE 3.5 SP2 and are now referencing the System.Data.SqlServerCe.dll in the Private folder we are getting a versioning error.

Unable to load the native components of SQL Server corresponding to the ADO.NET provider of version 8080.  Install the correct version of SQL Server Compact.  Refere to KB article 974247 for more details.

I have checked the version of SQL Server Ce installed on my computer and it is 8080 in Program Files and in the GAC.

If we go back to the SQL Server CE 3.5 SP2 assembly in the Desktop folder we do not receive this error.  So it looks like we cannot switch to this new private folder in SQL Server CE 3.5 SP2 and have it compatibly with our .SDF file.

Is there any way to covert a .SDF file created with SQL Server CE 3.5 SP1 (Desktop) to SQL Server CE 3.5 SP2 (Private)?  Is is hopefully possible  because this private folder and assembly did not exist until SP2. :(

Answer 4

There is no file format changes between SP1 and SP2. Follow the guideline in 3.5 SP2 Books Online (http://www.microsoft.com/downloads/details.aspx?FamilyID=746C3A6E-FFB1-4C92-93FA-B3BA41FDE681&displaylang=en)

in the topic called: Private Deployment vs. Central Deployment (SQL Server Compact)

ms-help://MS.SSC.v35/MS.SSC.v35.EN/sscprog/html/12abe1fd-d5da-48a0-8ef2-76bd3ef6c03a.htm

---

http://erikej.blogspot.com Erik Ejlskov Jensen - Please mark as answer, if this was it.

Answer 5

Thank you very much Erik and Imran!

We were referencing the correct System.Data.SqlServerCe.dll in our project from the %Program Files%\Microsoft SQL Server Compact Edition\v3.5\Private folder.

What we failed to do was create the X86 and AMD64 directory in our debug direcotry for our main project and add the native components.

We put these directories under the application folder in our build, but when we refenced the new dll we needed to also add the X86 and AMD64 directories in the debug directory.

This was for a 64-bit build.  I'm assuming on our 32-bit build we'll just need to add the 32-bit native components in the debug directory.

Again, thank you for your help.  Both pieces of advice helped us through this issue, but re-reading the documentation got us thinking about adding these directories to the debug directory in our main project.

Answer 6

That sshould not be neccessary to do (adding files to the debug directory). Include both sets of native DLLs and include them as content, as described here: http://blogs.msdn.com/b/stevelasker/archive/2008/10/22/privately-deploying-sql-server-compact-with-the-ado-net-entity-provider.aspx

---

http://erikej.blogspot.com Erik Ejlskov Jensen - Please mark as answer, if this was it.

Answer 7

Hello Eric:

I'm linking to the files now in my project as per the instructions on the link provided.  I've been able to make a 64-bit build using the DLLs in the private directory and including the all the Native components in their respective directories.

I've uninstalled SQL Server CE 3.5 SP2 and the program is still running without any issues.  Thank you once again for the help you've provided.

--Todd

Answer 8

Does not matter where the dlls were copied from. Since GAC also has 3.5.1 (from SP1), privately deployed SQL CE assembly (SP2 but still versioned 3.5.1) is never loaded. Why are both SP1 and SP2 versioned the same?

What's a workaround?

Answer 9

Use the file from the private folder, it has assembly version 3.5.1.50, so does not clash with anything in GAC - see my blog for more info - http://erikej.blogspot.dk/2012/05/private-deployment-of-sql-server.html

---

Please mark as answer, if this was it. Visit my SQL Server Compact blog