Ciao Giorgio,
prova ad usare Entity Framework con l'approccio code first; ti dovrebbe consentire di creare il database SQLCE senza dover installare alcuna strumentazione in Visual Studio Express.

Ecco il pacchetto da scaricare con nuget.
https://www.nuget.org/packages/EntityFramework.SqlServerCompact/
E qui trovi un articolo che parla appunto di Code First con SQLCe.
http://www.codeproject.com/Articles/680116/Code-First-with-SQL-CE

orsattigiorgio ha scritto:

LocalDB può essere utilizzato dopo la prima fase di sviluppo sul server di Aruba?

Sì, il formato è quello di Sql Server, ma non potrai fare il deploy del file .mdf insieme agli altri file dell'applicazione. Dovrai per prima cosa acquistare un database (oltre al servizio di hosting che già hai) e poi importare il tuo database dal loro pannello di gestione.
http://kb.aruba.it/KB/a4645/come-gestire-ms-sql-server.aspx?trans=1&forcetrans=true

ciao,
Moreno

ciao Giorgio,

orsattigiorgio ha scritto:

grazie per a risposta, e per il deploy?

Questo dipende molto dall'hosting provider che hai scelto. Nel caso di Aruba, dovrai importare il database dal loro pannello di gestione, come ti dicevo nel post precedente.

Se invece disponi di un server che supporta la modalità di pubblicazione Web Deploy (come su Windows Azure), il database può essere ricreato al momento del deploy, per mezzo di script. Questa procedura è documentata qui.
http://msdn.microsoft.com/en-us/library/vstudio/dd465343(v=vs.100).aspx

orsattigiorgio ha scritto:

Con Visual Studio 2013 generavo automaticamente quanto necessario per il deploy.

Già, ma la modalità definita "XCopy" (copia pari pari di tutti i file sul server) non è proprio ideale per pubblicare dei database.

Un database ha due caratteristiche che evolvono indipendentemente l'una dall'altra: lo schema e i dati.
Mentre apporti modifiche alle sue tabelle dal tuo PC di sviluppo, il database che avevi pubblicato ieri sul server si è già riempito di dati di produzione.

Se non vuoi perdere quei dati, non ti è possibile ripubblicare alla cieca la nuova versione del database. Devi fare in modo di eseguire degli script sul database di produzione, così che la struttura venga aggiornata (magari hai aggiunto una colonna) senza che i dati vadano persi.

Se fai queste operazioni manualmente, alla lunga rischi di commettere un errore e perdere dei dati oppure di creare dei disservizi.
Un modo per affrontare dignitosamente questo problema è usare le code-first migrations. Trovi un'introduzione in questo articolo di Stefano Mostarda.
http://www.linqitalia.com/articoli/entity-framework/introduzione-entity-framework-code-first-migrations-43.aspx

Qui c'è una guida passo passo per creare un progetto dimostrativo che sfrutta le migrations.
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application

I più grossi vantaggi, secondo me, sono questi che ti elenco qui di seguito, e surclassano qualsiasi altro tipo di pubblicazione database.

• Le migrations sono descritte da file di codice, che perciò entrano nel controllo di versione. Potrai sapere con esattezza quali campi hai aggiunto e quando.
• Ogni migration prevede due script: uno di upgrade e uno di downgrade. Se ti dovessi accorgere che le nuove modifiche che hai appena apportato al database stanno causando dei problemi, puoi tornare indietro immediatamente. Sfido a fare la stessa cosa manualmente, con la stessa tranquillità.
• Deployare il database a quel punto diventa semplicissimo, perché con la solita modalità di pubblicazione Web Deploy, gli script di upgrade delle migrations verranno ripetuti tali e quali sul server. Ecco la finestra del wizard di pubblicazione da cui puoi indicare di ripetere le migrations sul server.

ciao,
Moreno