Support Staff2 Posted by friism on 09 May, 2011 06:07 PM
Using instance-filesystems for persistence is not recommended on
AppHarbor. The files are zapped on deploy and are not synchronized
if your app runs on multiple instances.
Having said that, unless you've enabled the Allow
write-access to file system, you should stash the sdf file
in the App_Data folder of your website. This is the
only folder writeable by the application.
We are encountering the same issue here, all dll referenced
using Nuget and also deployed the dll using the
_bin_deployableAssemblies folder, and there nothing we can do to
make this work. Is there anything you can do with KB 974247?
I've made my way through the AppHarbor sample project you are
referring to, but it uses SqlServerCe differently, only opening a
connection in code to a SDF file, whereas our issue occurs on
AppHarbor servers when we use SqlServerCE with
System.Web.Providers, as the database for the user and role
database. The application fails while reading the application
configuration file when it tries to instantiate the
However, such error does not occurs on our machines. Is it
possible for you to look at the KB or else simply install the
binaries for SqlServerCE http://www.microsoft.com/download/en/details.aspx?id=17876
on your servers, which I do not know if its feasible, but would be
great, sometime we just need a very small store (which we know will
get erased on each deployement)
Support Staff5 Posted by friism on 27 Jul, 2011 08:23 PM
Kevin, thanks for your detailed description. We are wary of
installing additional components on appharbor application servers.
One of the reasons is to not crud up the GAC since this can cause
GAC-dll-overriding problems for people that want to use
non-standard versions of software components.
Your problem seems to be caused by the fact that the AppHarbor
servers that build your code has some version of SQL Server CE
installed (due to some other long forgotten expediency). When the
code is compiled, it is linked to the GAC-installed version. The
code is then deployed to a different server without SQL Server CE
installed, and the version you bin-deploy with your code is
incompatible with the one linked to during build. This causes the
As a temporary measure, you could try to bin-deploy 32bit
versions of SQL Server CE 3.5.0 or 3.5.1 (which is what is
currently found on our build servers). We're trying to come up with
a general solution (which might end up be, making sure that build
and application servers are configured the same) and will keep you
Support Staff7 Posted by friism on 31 Jul, 2011 05:27 AM
OK, this can be made to work, I'm attaching a rough solution
Here are the approximate steps I took:
1) add SqlServerCE and System.Web.Providers using nuget
2) Make SqlServerCE a deployable dependency (this causes the native
dll's to be placed in a _bin_deployableAssemblies
folder. Normally these are copied to the output dir by msbuild, but
not on AppHarbor for various reasons)
3) Add the following to your project file to cause the native dll's
to be copied to the build output (replace
WebProvidersTest with your project name):
Note that I also upgraded the SqlServerCE.dll (and the entity
one) to 22.214.171.124 (found in the private folder of the
SqlServerCE installation dir). This is useful to avoid getting
overwritten by GAC-installed 126.96.36.199 version, but I don't actually
think it's necessary here, because Sql Server CE is not installed
on AppHarbor application servers.
You may also need the assemblybinding-stuff at the bottom of the
I've tried all the step in you last post but now there is still an error
while loading the application*
*Server Error in '/' Application.
*Failed to find or load the registered .Net Framework Data Provider.*
*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.Configuration.ConfigurationErrorsException:
Failed to find or load the registered .Net Framework Data Provider.
An unhandled exception was generated during the execution of the current
web request. Information regarding the origin and location of the exception
can be identified using the exception stack trace below.
From what I can see on the build server, the DLL are copied :
if not exist
xcopy /s /y
Support Staff9 Posted by friism on 01 Aug, 2011 08:53 PM
For the assembly-binding, are you sure you're using 188.8.131.52 and
not 184.108.40.206 (that is, if you use the straight-up nuget dll's). If
that's not it, you might want to try with the 220.127.116.11 dlls found in
the "private" folder of you SqlServerCE installation.
Support Staff16 Posted by friism on 03 Aug, 2011 03:17 AM
I'm attaching a working copy of your code (since deleted for
security reasons). I think the problem was due to bad references to
the sqlserverce and sqlserverce.entity dlls. I've included the git
versioning info in the archive, so that you can see what it took to
get it running. Not all steps may be necessary.