Connexion d'une base de données existante dans l'application pendant l'installation: Projet d'installation

Question

J'ai une application C# windows en cours d'exécution dans Visual Studio 2013 pour laquelle j'ai créé un programme d'installation en utilisant l'installation et le déploiement. Pour cette application, j'utilise la base de données MySQL comme une entité distincte qui a un script de création de table, une procédure stockée et un fichier batch de base de données pour exécuter tous les scripts.

Mais maintenant j'ai besoin d'envoyer cette base de données candidate dans le programme d'installation. J'ai essayé quelques options comme l'exécution du fichier batch de la base de données dans l'action personnalisée après la validation, ce qui ne s'est pas bien passé. Si je ne veux pas utiliser la méthode d'exécution de fichier batch (Parce qu'aucune des options exécutant le fichier batch à la fin de l'installation n'a fonctionné pour moi) comment puis-je attacher cette base de données existante à mon projet d'installation au moment de la validation?

Je gère les connexions dans le code de l'application en prenant la chaîne de connexion de appconfig.

<connectionStrings> 
    <add name="CRSDatabaseString" connectionString="Server=localhost; Database=Tel_CRS; Uid=root; Pwd=root123; Persistsecurityinfo=True;" /> 
    <add name="CSSDatabaseString" connectionString="Server=localhost; Database=Tel_css; Uid=root; Pwd=root123; Persistsecurityinfo=True;" /> 
    </connectionStrings> 

Et le code dans l'application connexion SQL comme suit:

public MySQL_Connection() 
     { 
         String conn =""; 
      if (Bootstrapper.InspectionTarget=="css") 
       conn = ConfigurationManager.ConnectionStrings["CSSDatabaseString"].ConnectionString; 
      else 
       conn = ConfigurationManager.ConnectionStrings["CRSDatabaseString"].ConnectionString; 


      Db_conn = new MySqlConnection(conn); 
      Db_conn.Open(); 
     } 

Answer 1

Il y a plusieurs raisons pour lesquelles cela pourrait ne pas fonctionner dans une action personnalisée Visual Studio. La plus courante est que les actions personnalisées s'exécutent avec le compte système (de sorte qu'elles sont élevées) dans une installation Tout le monde (par machine), et les bases de données n'autorisent généralement pas l'accès au compte système. Un autre peut être que la base de données est sur un réseau, mais le compte système n'a pas de privilèges d'accès réseau. Il n'est pas clair si votre code s'exécute à partir d'un exécutable ou d'une classe d'installation Dll, mais de toute façon le code n'est pas exécuté dans le même contexte que celui exécuté à partir du shell Windows pour le compte de l'utilisateur interactif: il n'y a pas de répertoire de travail par défaut (vous utilisez un processus msiexec.exe); l'accès aux emplacements du profil utilisateur échouera (le compte système n'a pas de dossier de bureau, par exemple) et dans une classe d'installateur Dll les fichiers de configuration/paramètres ne sont pas disponibles de manière habituelle car les classes d'installateur sont instanciées avec réflexion. manière de chargement d'assemblage. En d'autres termes, le fait que le code s'exécute lorsque vous le testez en tant qu'utilisateur interactif ne signifie pas qu'il fonctionnera avec le compte système et s'exécutera à partir d'un processus msiexec.exe.

Il est peut-être préférable d'effectuer cette opération lorsque l'utilisateur essaie d'utiliser l'application (et PAS à partir de l'installation), en particulier si vous disposez déjà du code pour le faire. Ensuite, il fonctionnera dans un contexte d'utilisateur normal et peut facilement être réessayé s'il échoue, ce qui peut ne pas être le cas s'il échoue lors de l'installation.