Porter une application SqlServerCE 3.5 vers la nouvelle version 4.0

13. mars 2011

Avec la sortie du SP1 de Visual Studio 2010, je me suis motivé pour porter UrzaGatherer vers SqlServerCE 4.0.

Voici donc les étapes que j’ai suivies:

using (SqlCeEngine sqlCeEngine = new SqlCeEngine(“connectionString”))
{
      sqlCeEngine.Upgrade();
}

Par la suite il est possible d’utiliser les nouveautés style la génération de clefs mais dans mon cas comme je ne veux pas modifier ma base, cela s’arrêtera la.

En ce qui concerne Entity Framework,j’ai juste eu à changer la chaine de connexion pour remplacer le numéro de version:

provider=System.Data.SqlServerCe.3.5—>provider=System.Data.SqlServerCe.4.0

Il faut également modifier le .edmx à la main pour modifier la référence au bon provider:

<Schema Namespace="UrzaGathererModel.Store" Alias="Self" Provider="System.Data.SqlServerCe.3.5" ProviderManifestToken="3.5" … >

—>

<Schema Namespace="UrzaGathererModel.Store" Alias="Self" Provider="System.Data.SqlServerCe.4.0" ProviderManifestToken="4.0" … >

 

Une fois toutes ces modifications effectuées, il est possible de se servir de SqlServerCE 4.0 sans soucis et en profitant de toutes les améliorations.

Parmi ces dernières, celle qui m’a intéressé c’est le déploiement privé qui permet d’embarquer tout ce qu’il faut pour SqlServerCE 4.0 sans avoir ainsi besoin d’installer quoi que ce soit. Il suffit pour cela de rajouter et d’embarquer dans notre projet l’intégralité du répertoire C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v4.0\Private et le tour est joué!

 

Pour retrouver tout ça en live, vous pouvez télécharger le SUBLIME UrzaGatherer : http://urzagatherer.codeplex.com

NB: Je viens de voir que le SKIP de Linq marche désormais! Super bonne nouvelle^^

.Net ,

Entity Framework 4.0 et SQL Server CE

11. juin 2010

Je viens de faire le portage de UrzaGatherer depuis SQL Server 2008 R2 Express vers SQL Server CE 3.5 SP2.

Plusieurs choses sont bonnes à savoir pour que ce genre de portage se passe bien:

Le provider SQL Server CE pour Entity Framework 4.0 ne supporte pas la génération automatique des clefs il faut donc se faire une petite requête pour les générer:

Card card = new Card();
card.ID = (from c in Tools.Entities.Cards select c.ID).Max() + 1;

 

Les requêtes LINQ avec des jointures sont très mal supportées. Par exemple, ce genre de requêtes est extrêmement lent:

 var query = from card in Tools.Entities.Cards
     join blk in Tools.Entities.Blocks on card.Expansion.BlockID equals blk.ID
     where (expansionID == 0 || card.ExpansionID == expansionID) && 
(blockID == 0 || blk.ID == blockID) select card.Expansion.Name; expansionsCount = query.Distinct().Count();

La version suivante donne le même résultat mais avec un gain de performances de l’ordre de 20:

var query = from card in Tools.Entities.Cards                            
            where (expansionID == 0 || card.ExpansionID == expansionID) 
&& (blockID == 0 || card.Expansion.BlockID == blockID) select card.ExpansionID; expansionsCount = query.Distinct().Count();

Les comparaisons de chaines sont un peu hasardeuses. Par exemple le code suivant provoque un bug:

 from card in expansion.Cards
 where
    (card.Color.Name == filterColor || filterColor == " ")                     
 select card;

Le provider dans ce cas la se prend un peu les pieds dans le tapis et considère que la chaine filterColor doit faire une longueur de 1 (à cause du “ “). Il faut donc évaluer au préalable la valeur de test:

 bool enableColorFilter = filterColor != " ";

 return from card in expansion.Cards
            where
                   (card.Color.Name == filterColor || !enableColorFilter)
            select card;

Il faut aussi tenir compte du fait que le Skip() et le Take() ne sont pas gérés.

Pour le reste, le provider s’en sort très bien et le résultat est excellent.

.Net