Créer sql server compact fichier dans le dossier appdata

Je suis en train d'élaborer un simple morceau de logiciel qui utilise Entity Framework code first et sql server compact 4. Au moment où cette configuration fonctionne. Entity framework crée le serveur sql server compact fichier si il n'existe pas encore de. Le chemin d'accès à la base de données est défini à partir de l'intérieur d'un connectionstring qui est stocké à l'intérieur de l'app.fichier de configuration. Elle est construite comme ceci:

<connectionStrings>
  <add name="DataContext" 
       connectionString="Data source=Database.sdf;"
       providerName="System.Data.SqlServerCe.4.0"/>
</connectionStrings>

Cependant, je veux placer la base de données dans un dossier dans le courant de l'utilisateur du dossier de Données d'Application (le C:\Users\User\AppData\Roaming dossier sur mon win7 machine). J'ai essayé le réglage de la source de Données de la propriété connectionstring pour quelque chose comme le %APPDATA%de la Base de données.sdf, mais cela ne fonctionne pas, j'obtiens un "caractères Illégaux dans le chemin de" l'exception".

Je veux coller avec la connectionstring méthode, parce que je voudrais utiliser une autre base de données pour mes tests d'unité qu'avec mon application réelle. De cette façon, il est facile de modifier la base de données en plaçant une application.fichier de config à la racine du projet.

Quelqu'un peut-il m'orienter dans la bonne direction?

Mais de cette façon, je dois construire la connectionstring dans le code. Ce ne sera pas facile de changer l'emplacement de la base de données, comme je le fais maintenant. J'ai une autre application.fichier de config à la fois de mon projet et de mon projet de test, qui pointent tous deux vers une autre base de données.

OriginalL'auteur Jesse van Assen | 2011-10-03

c#entity-framework-4.1 sql-server-ce

22

Ci-dessous:
```
AppDomain.CurrentDomain.SetData("DataDirectory", Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData));

<connectionStrings>
  <add name="DataContext" 
       connectionString="Data source=|DataDirectory|Database.sdf;"
       providerName="System.Data.SqlServerCe.4.0"/>
</connectionStrings>
```
Merci, cela fonctionne. L'application est une application wpf, et j'ai placé le domaine d'application de la ligne dans l'Application.xaml.cs méthode de démarrage.
Vous êtes les bienvenus.
Vous avez besoin d'ajouter un autre tube avant "DataDirectory" (|DataDirectory|). Juste pensé que cela pourrait aider quelqu'un car je suis bloqué sur la pour un tandis que! msdn.microsoft.com/en-us/library/cc716756(v=vs. 100).aspx
Le manque de pipe (|) a été ajouté dans l'édition.

OriginalL'auteur Teoman Soygul
3
```
    connectionString="Data source=Database.sdf;"
```
Cela indique à votre application pour rechercher la Base de données.sdf dans votre app du répertoire de travail actuel; ce qui pourrait être n'importe où et peut ne pas être accessible en écriture. Vous avez besoin de regarder un emplacement que vous spécifiez:
```
    connectionString="Data source=|DataDirectory|Database.sdf;"
```
ADO.NET recherche pipe caractères dans les chaînes de connexion et s'étend à la valeur de la propriété de ce nom dans le domaine de l'application. Alors, quelle est la valeur de la DataDirectory propriété? C'est censé être réglé par quoi que ce soit déployé votre application:
- .MSI installateurs de définir à l'installation de l'application un dossier. Si vous permettez à l'utilisateur de choisir le dossier d'installation, ils choisissent le DataDirectory. C'est pourquoi vous devez toujours utiliser |DataDirectory| et jamais codé en dur chemin.
- ClickOnce définit un ensemble de données particulières du dossier de votre projet.
- Les applications Web utilisent le dossier App_Data.
- Le débogueur Visual Studio utilise le dossier de débogage.
Toute Visual Studio fichiers de votre projet avec un “copier vers un répertoire de sortie” de la propriété sera copié à DataDirectory. Dans la plupart des cas DataDirectory sera un dossier en lecture seule. C'est très bien si vos données sont en lecture seule, mais si vous voulez écrire, vous devez copier vos données à un emplacement accessible en écriture. Probablement le meilleur endroit est Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData)). Il y a plusieurs façons de le faire:
- Si vous créez un vide nouveau fichier de données, il suffit d'utiliser votre API standard CREATE DATABASE ou new SqlCeConnection() ou quoi que ce soit.
- Si vous souhaitez commencer avec un pré-rempli de graines ou de démarrage de la base de données, comprennent les semences de base de données dans votre projet . Dans votre démarrage de l'application, vérifier si la base de données existe dans le SpecialFolder.ApplicationData dossier et, si non, le copier.
Si vous rechercher sur le web pour un exemple de code sur la création d'une base de données locale vous allez courir à travers beaucoup de mauvais conseils. Ne pas effectuer les opérations suivantes:
```
new SqlCeConnection(@"Data source=c:\users\me\myApp\Database.sdf;");  //Do NOT do this!
```
J'espère que je n'ai pas à expliquer pourquoi coder en dur le chemin d'accès à vos données est mal; mais il faut être conscient que, sauf si vous spécifiez un chemin d'accès complet dans votre chaîne de connexion, le chemin est relatif au répertoire de travail courant.
```
using (var conn = new SqlCeConnection(@"Data source=|DataDirectory|Database.sdf;"))
{
    conn.Open();
    //No No No! This throws an Access Exception for Standard users,
    //and gets deleted when you repair the app!
    var cmd = conn.CreateCommand("INSERT INTO Table (column1, column2) VALUES (@p1, @p2)");
    ...
}
```
N'essayez pas de modifier les données dans DataDirectory. Non seulement est-ce répertoire est pas toujours modifiables par les utilisateurs, il est possédé par le programme d'installation non par l'utilisateur. La réparation ou de la désinstallation de l'application va supprimer toutes les données de l'utilisateur; les utilisateurs n'aiment pas ça. Au lieu de cela, copiez les données installés dans un dossier accessible en écriture par l'utilisateur et de faire toutes les modifications apportées à la copie.
```
AppDomain.CurrentDomain.SetData("DataDirectory",
    //Wrong, this overwrites where the user installed your app!
    Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData));
```
Ne modifiez pas la valeur de DataDirectory dans votre code, il est défini par l'installateur et si vous changer, vous ne saurez pas où vos données a été installé. Si vous êtes à la création d'une base de données vide, il suffit de l'ouvrir dans votre emplacement final. Si vous allez faire une copie, ouvrez la base de données installée, l'enregistrer à l'emplacement de l'utilisateur, à proximité de la base de données installée, et ouvrez la copie.

J'ai aussi décourager l'enregistrement des données à Environment.SpecialFolder.CommonApplicationData. Cela peut ne pas être accessible en écriture par l'utilisateur, et à moins qu'il y est une très très bonne raison de tous les utilisateurs doivent être autorisés à modifier les données d'autres utilisateurs, chaque utilisateur doit disposer de leur propre base de données.

OriginalL'auteur Dour High Arch

Vous devez vous connecter pour publier un commentaire.