2009-03-27 3 views
1

Grâce à ce site Web, j'ai réussi à utiliser une connectionString localisée dans un web.config au lieu de celle fournie dans le fichier app.config de la bibliothèque. Mais ma production et mon test SQL Server n'ont pas le même nom d'utilisateur SQL.Déployer une bibliothèque LINQ to SQL à l'aide de différents utilisateurs SQL

Table(Name="SqlUserName.tableName")] 
public partial class tableName : INotifyPropertyChanging, INotifyPropertyChanged 
{ 
    ... 
} 

Lorsque je supprime manuellement le nom d'utilisateur avant le nom de la table, cela fonctionne. Mais j'ai encore des problèmes:

  1. Est-ce bon de le faire? Peut-être qu'il y a un défaut potentiel dont je ne suis pas au courant.
  2. Si c'est un bon comportement, comment puis-je le configurer quelque part? Chaque fois que LINQ régénérera le dbml, je perdrai ma modification. Je pense que je ne peux pas le déplacer vers une classe partielle car c'est un attribut et ne peut pas être redéfini (je ne veux pas le faire aussi pour toutes les tables).

Merci pour votre aide.

+0

J'ai ajouté une question à un problème similaire ici http://stackoverflow.com/questions/2159516/linq-to-sql-need-different-usernames-for-prod-and-dev-dbml-on-table-attribute avez-vous trouvé un bonne solution à cela? – CRice

+0

Oui, j'ai utilisé le schéma dbo partout, de cette façon je peux utiliser Table (Name = "dbo.tableName")] dans tous les environnements – Gabriel

Répondre

0

Enfin j'ai utilisé le schéma dbo pour toutes les tables que j'ai créé, ainsi j'ai supprimé la dépendance de l'utilisateur et LINQ pourrait générer à nouveau le DBML sans casser le déploiement:

Table(Name="dbo.tableName")] 
public partial class tableName : INotifyPropertyChanging, INotifyPropertyChanged 
{ 
    ... 
} 
0

Utilisez le même nom pour les chaînes de connexion dans le serveur local et distant web.config, mais utilisez un nom d'utilisateur et un mot de passe différents pour ces chaînes. Je suis cette pratique et c'est parfaitement pour moi.