That line on its own is innocuous - it sets the default connection factory that is then used to resolve the provider and the database connection string *if you don't explicitly specify the connection string in the model or when creating the context*.   If you look at our samples and even the XML we show in our documentation reflect the default for EF which is the SQL LocalDb connection factory.

Reading the source code for the SqlCeConnectionFactory if you pass it a string without an = in it, it assumes it's the file name of the database to open and it then tries to create the SqlCe provider.  I'd expect that provider *does* exist on your development system (installed with Visual Studio) but would not generally be available on a client, causing a failure at runtime there.

You can avoid the connection factory by having a connection string name configured in your DbContext or specifying the name/connection string when you create the DbContext each time.  Meanwhile, we're working to create a version of the connection factory for VistaDB.

So the issue is resolved?  Indeed, setting that copy local option is a critical step to ensure you're distributing the VistaDB engine.

I see two other issues:

1. You need to include the VistaDB5 ADO.NET provider itself in the configuration file, not just the EF provider.

2. I'm not sure you're going to get success with the "SqlCeConnectionFactory"

I'd recommend carefully reading through our deployment guidance:
http://www.gibraltarsoftware.com/Support/VistaDB/Documentation/WebFrame.html#DevelopersReference_Deployment.html

We highly recommend against putting the assemblies in the GAC;

The configuration file you sent in the zip file looks right.

We don't provide a VistaDB implementation of the EF 6 IDbConnectionFactory - which is an oversight. I'll talk to the team and have them make that.  Looking at our samples and our own usage, we've tended towards passing in a complete connection string to the DbContext overload that takes a connection string.  I think by using the SqlCeConnectionFactory you're pushing it to use the SqlCe ADO.NET provider, not sure - we can't see from the error message what provider it's actually looking for.

You've sent us down a good road - Digging into this just a little we can easily create a VistaDBConnectionFactory and publish it out to NuGet.  That should remove the need to explicitly register the VistaDB provider with EF as well.  That said, looking at the source code of Microsoft's implementation of SqlCeConnectionFactory it does hardcode their ADO.NET provider which explains the error your getting (in other words, that's just not going to work).