A propos des paramètres de projet.

Bonjour à tous,

Avez-vous déjà utilisé les paramètres d'un projet accessible dans le code via My.Settings.LeNomDuParametre ?

Pour les paramètres d'un projet winform, pas de soucis. Ils se trouvent dans LeProjet.exe.config et peuvent facilement être modifié sans devoir recompilé l'application.

Là où je m'emmêle les pinceaux, c'est pour utiliser ces paramètres pour un projet de type bibliothèque de classes.

Dans le folder bin\debug de la bibliothèque, il y a le fichier LeProjet.dll.config avec les paramètres dedans.

Par contre, ce fichier n'est pas copié vers le folder bin\debug de l'application winform qui référence la bibliothèque. Mais malgré cela, la dll parvient bien à utiliser ses paramètres. Du coup, je ne pige pas trop.

J'ai regardé un peu sur le net et il semblerait que les paramètres avec leur valeur "par défaut" (ie : encodées dans VS) sont compilés dans la dll. Mais du coup, impossible de les modifier par après.

Je suis un peu perdu...

Pour info, le process est le suivant :

Dans la couche GUI, l'utilisateur scanne un barcode de type EAN128.
La BLL vérifie si le barcode est correct et si oui, l'envoi vers la DB et aussi dans un fichier txt. Et c'est pour définir où créer ce fichier que j'ai utilisé les settings de la dll.

Ferais-je fausse route et faut-il définir ces settings dans la couche GUI ? Cela me donne l'impression que la couche GUI se mêle alors de choses qui ne la regarde pas.
De plus, si je les mets dans la GUI et plus dans la BLL, la couche BLL ne compilera plus vu que les paramètres n'existent pas... Bref, c'est le bordel :aie:

Qu'en pensez-vous ?

Bonjour,

Citation:

---

Envoyé par Kropernic

Par contre, ce fichier n'est pas copié vers le folder bin\debug de l'application winform qui référence la bibliothèque. Mais malgré cela, la dll parvient bien à utiliser ses paramètres.

---

Mais là c'est pour le développement.
Qu'en est-il lors de l'installation réelle ?
Une fois l'appli installée avec sa dll et le fichier de config de la dll "LeProjet.dll.conf", la modification du chemin du fichier texte en sortie dans "LeProjet.dll.conf" est elle prise en compte quand tu utilises l'appli ?

Je viens de faire un test.

J'ai pris la fichier .config qui se trouve dans le folder bin\debug du projet bibliothèque de classe et je l'ai copié dans le folder bin\debug du projet winform.
J'ai alors modifié le paramètre pour que le fichier à créer le soit dans un autre folder et j'ai fait tourné l'application.

Cela n'a eu aucun effet. Le fichier est toujours créé à son emplacement d'origine.

Oui, mais là tu es toujours en developpement.
Place tout dans un répertoire (exe, dll, fichiers config) et lance l'exe

Question subsidiaire, comment fais-tu avec ta chaîne de connexion BDD ?

Citation:

---

Envoyé par rv26t

Oui, mais là tu es toujours en developpement.
Place tout dans un répertoire (exe, dll, fichiers config) et lance l'exe

---

Ok je vais tester ça mais je ne vois pas ce que ça va changer.

Sinon pour info, je viens de tester ceci :

• Modifier GUI.exe.config pour ajouter :
  Code:

  ---

  1 2 3 4 5 6

  <BLL.My.MySettings> <setting name="storageFolder" serializeAs="String"> <value>\\serverXXX\d$\OTHER_DATA\SEALBAG1\</value> </setting> </BLL.My.MySettings>

  ---

  Cela fait planter l'application au lancement XD
• Modifier GUI.exe.config pour ajouter entre les balises usersSettings :
  Code:

  ---

  1 2 3 4

  <setting name="storageFolder" serializeAs="String"> <value>\\serverXXX\d$\OTHER_DATA\SEALBAG1\</value> </setting>

  ---

  L'application ne plante pas mais cela n'a aucun effet.

Je vais donc maintenant tester ce que tu suggères et je viens donner le résultat.

Voilà, je viens de tester (c'était vite fait faut dire). Cela ne change rien. La valeur mise dans le fichier BLL.dll.config n'est pas prise en compte.

Bonjour,

Quelle est la porté de storageFolder? Utilisateur ou application?

Citation:

---

Envoyé par rv26t

Question subsidiaire, comment fais-tu avec ta chaîne de connexion BDD ?

---

Héhé, bien vu l'aveugle ! Même problème que j'ai contourné provisoirement en ajoutant un fichier DB.dat au projet GUI qui est toujours copier à la compilation. Dans la DAL, je fais :

Code:

---

1 2	Dim sr as new IO.StreamReader("DB.dat") Dim server = sr.ReadLine()

---

Et j'injecte le serveur ainsi obtenu dans la chaîne de connexion.

Mais ouais, idéalement, j'aimerais passer par les settings de la DAL aussi...

Citation:

---

Envoyé par Sankasssss

Bonjour,

Quelle est la porté de storageFolder? Utilisateur ou application?

---

Utilisateur :mrgreen:

EDIT : Je viens aussi de tester en mettant le paramètre dans les settings de la couche GUI (on ne sait jamais). Mais cela ne change rien.

Je commence à me dire qu'il va falloir que la GUI dise à la BLL où stocker le fichier. Je trouve cela bizarre car pour moi, c'est la logique métier qui dicte où stocker le fichier en question. La GUI n'a d'ailleurs pas à savoir qu'un fichier est créé. Son rôle se cantonne à scanner à barcode et à dire à la BLL ce qu'elle a scanné.

Me trompe-je ?

J'ai l'impression que tu te compliques la vie.
Même si tu utilises des DLL pour la DAL et la BLL, à un moment tu instancies des classes de ces DLL dans ton appli, cela na rien a voir avec l'UI, donc à ce moment tu lis les setting de l'appli et les passes en paramètres aux instances des classes de DLL que tu cré. Non ?

Je viens de tester et effectivement je ne retrouve pas où est stockée l'information, le plus spécial étant que l'on peut la changer et la sauvegarder (My.Settings.Save()) au niveau du projet qui utilise la library sans impacter d'autres projets donc il doit bien la stocker quelque part.

Citation:

---

Envoyé par rv26t

J'ai l'impression que tu te compliques la vie.
Même si tu utilises des DLL pour la DAL et la BLL, à un moment tu instancies des classes de ces DLL dans ton appli, cela na rien a voir avec l'UI, donc à ce moment tu lis les setting de l'appli et les passes en paramètres aux instances des classes de DLL que tu cré. Non ?

---

Jamais aucune classe n'est instanciée pour la DAL et encore moins par la GUI. Ce ne sont que des méthodes/fonctions Shared et elles sont toutes consommées uniquement par la BLL (et la DAL quand le process le nécessite).

Mais si je suis ton raisonnement, cela voudrait dire que, à chaque fois que je instancie un objet de la BLL, la GUI doit lui donner le nom du serveur de DB pour que cette dernière (la BLL) puisse le transmettre à la DAL lors de l'appel de la méthode de persistance...

Cela parait tordu et il doit y avoir moyen de faire mieux mais, sur le fond, je commence à croire que c'est la voie à suivre car...

Prenons le cas d'une application avec une interface en winforms pour une utilisation interne à l'entreprise et une interface web pour une utilisation externe. Je n'ai pas d'idée précise sur la raison qui pourrait pousser à vouloir faire cela mais on pourrait imaginer que lorsque c'est l'interface winforms qui est utilisée, il faille accéder à une DB A. Alors que lorsqu'on utilise l'interface web, on accède à une DB B.
Dans ce cas, soit la DAL doit être informée de l'interface qui est utilisée pour pouvoir adapter la chaîne de connexion (mais il faut alors recompiler la DAL pour chaque nouveau type d'interface utilisé), soit la DAL doit être informée de la chaîne connexion (ce qui ne nécessite pas de recompilation ultérieure).

Reste à trouver une façon élégante de faire cela (informer la DAL). Malgré tout, je trouve quand même cela bizarre que ce soit la GUI qui décide de la chaîne de connexion de la DAL.

Idem donc pour les paramètres de la BLL pour l'endroit où stocker le fichier.

Il me semble que les settings sont stockés dans %userprofile%\AppData\Local\

+1 DotNetMatt
On peut le voir avec

Code:

---

ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath

---

et en référençant System.Configuration.dll.

Euh... Je veux bien mais je ne trouve pas le fichier qui les stockerait dans ce folder...

J'imagine bien qu'il est quelque part dans un sous-folder mais lequel 0_0

Je ne trouve rien qui reprendrait le nom de mon application. Enfin si, j'en ai trouvé mais la dernière modif est à 11h56 alors que j'arrête pas de faire des modifs...

Avec le code que je t'ai mi plus haut j'ai :

Citation:

---

C:\Users\Gaëtan\AppData\Local\WindowsApplication1\WindowsApplicationTestCla_Url_4rchwfrqsjreqw1yxj3crcx5sx1oggha\1.0.0.0\user.config

---

qui contient :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="ClassLibrary1.My.MySettings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> </sectionGroup> </configSections> <userSettings> <ClassLibrary1.My.MySettings> <setting name="varTest" serializeAs="String"> <value>4</value> </setting> </ClassLibrary1.My.MySettings> </userSettings> </configuration>

---

Citation:

---

Envoyé par Sankasssss

Avec le code que je t'ai mi plus haut j'ai :

---

Ouais mais ce code ne fonctionne pas chez moi...

Faut un imports en début de classe ? J'ai tenté en important System.Configuration mais rien n'y fait.

EDIT : Fallait aussi ajouter la référence. Au temps pour moi.

Bon...

J'ai donc ajouté MsgBox(ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath) dans la GUI.
J'otiens bien un chemin de fichier et il me dirige vers un fichier que j'avais déjà trouvé mais donc la dernière modif remonte à 11h56 et qui contient ce qui suit :

Citation:

---

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
</configSections>
</configuration>

---

J'ai ensuite ajouté le même code également dans la BLL et j'obtiens le même fichier qui est toujours aussi vide. Je vais tenter d'y ajouter un paramètre pour voir si c'est pris en compte...

Je viens enfin de comprendre que ce fichier est utilisé uniquement quand on quitte l'environnement de dev. Il faut donc copier l'exe et les dll qui vont avec dans un autre folder et exécuter l'application pour que ce fichier user.config soit utilisé.

Sachant cela, j'essaie d'y ajouter le chemin d'accès au folder où je veux stocker le fichier.

A la base, le fichier contient ceci (j'ai ajouté un paramètre test pour voir la structure) :

Citation:

---

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<userSettings>
<SEALBAG_GUI.My.MySettings>
<setting name="test" serializeAs="String">
<value>hello world !</value>
</setting>
</SEALBAG_GUI.My.MySettings>
</userSettings>
</configuration>

---

Si j'ajoute

Citation:

---

<SEALBAG_BLL.My.MySettings>
<setting name="storageFolder" serializeAs="String">
<value>\\bru32srv929sql1\d$\OTHER_DATA\SEALBAG1\</value>
</setting>
</SEALBAG_BLL.My.MySettings>

---

en dessous de la section SEALBAG_GUI, j'ai une erreur qui dit

Citation:

---

Configuration system failed to initialize.

---

J'ai alors extrait le paramètre de la section SEALBAG_BLL pour le mettre dans SEALBAG_GUI mais il n'est pas pris en considération.

Il doit sûrement y avoir moyen mais je sèche ^^.

Pour répondre à tes questions, (hors sujet, mais important)

Citation:

---

Envoyé par Kropernic

Jamais aucune classe n'est instanciée pour la DAL et encore moins par la GUI. Ce ne sont que des méthodes/fonctions Shared et elles sont toutes consommées uniquement par la BLL (et la DAL quand le process le nécessite).

---

Je trouve cela moins objet, mais c'est juste mon point de vue.

Citation:

---

Envoyé par Kropernic

Mais si je suis ton raisonnement, cela voudrait dire que, à chaque fois que je instancie un objet de la BLL, la GUI doit lui donner le nom du serveur de DB pour que cette dernière (la BLL) puisse le transmettre à la DAL lors de l'appel de la méthode de persistance...

---

Non, en fait je cré un contexte de travail applicatif, contexte qui référence mon objet DAL une fois, après j'utilise les méthodes. (contexte accessible par l'UI, la BLL et la DAL)
Ce n'est donc pas la GUI qui informe la DAL de la chaîne de connexion (à travers la BLL), mais l'application elle-même au départ.
Ensuite l'UI consomme les méthodes de la BLL, et la BLL consomme les méthodes de la DAL à travers l'instance DAL du contexte de travail. Mon contexte contient une instance de la DAL, ce qui correspond à ton utilisation en shared mais plus dans le sens objet à mon gout, et d'autres choses.
Note : mon application est décompée en couche logique, pas sur des serveurs différents.
J'avais essayé de faire un chef d'orchestre applicatif ou chaque couche emettaient seulement des évènements, ce qui rendrait les couches totalement indépendantes les unes des autres, mais c'est très vide devenu :fou:

Il me semble que spring fourni une réponse, (qui peut correspondre à ce que tu souhaites) il faudrait voir dans le cours de serge tahe (en C#) apprentissage du langage C# à partir du chapitre 4 il aborde le sujet, je n'ai pas eu le temps d'approfondir.

Citation:

---

Envoyé par Kropernic

Cela parait tordu et il doit y avoir moyen de faire mieux mais, sur le fond, je commence à croire que c'est la voie à suivre car...

---

La façon dont je procéde est une approche personnelle pas forcément le mieux.

Pourrais-tu m'en dire plus sur ce que tu appelles un contexte applicatif ?

Citation:

---

Envoyé par Kropernic

Prenons le cas d'une application avec une interface en winforms pour une utilisation interne à l'entreprise et une interface web pour une utilisation externe. Je n'ai pas d'idée précise sur la raison qui pourrait pousser à vouloir faire cela mais on pourrait imaginer que lorsque c'est l'interface winforms qui est utilisée, il faille accéder à une DB A. Alors que lorsqu'on utilise l'interface web, on accède à une DB B.
Dans ce cas, soit la DAL doit être informée de l'interface qui est utilisée pour pouvoir adapter la chaîne de connexion (mais il faut alors recompiler la DAL pour chaque nouveau type d'interface utilisé), soit la DAL doit être informée de la chaîne connexion (ce qui ne nécessite pas de recompilation ultérieure).

Reste à trouver une façon élégante de faire cela (informer la DAL). Malgré tout, je trouve quand même cela bizarre que ce soit la GUI qui décide de la chaîne de connexion de la DAL.

---

Je pense que tu as mal choisi ton exemple, car la connection string doit se trouver normalement dans le fichier de config (app/web.config). Ce fichier étant présent à la racine de l'application (win/wpf/web), et les connection strings étant alors disponibles dans toute l'application. C'est la couche Business qui devra déterminer le contexte (web ou Windows), et indiquer à la DAL quelle connection string utiliser (ou la lui passer directement, au choix). Pas besoin de recompiler quoi que ce soit.

C'est une fabrication maison.
Plutôt que d'avoir des variables globales ou shared (ou des classes shared), j'ai une variable qui représente mon contexte de travail applicatif ou se trouve tout ce qui est commun à l'appli. Un peu à l'image d'une session windows mais au niveau applicatif (si tu vois ce que je veux dire)

Hello,

Je n'ai pas tout compris ce que vous avez dit.

Vu qu'il faut que j'avance, j'ai ajouté un fichier texte nommé BLL.conf dans la couche GUI et j'y stocke le path du folder où le fichier doit être stocker. Comme ça c'est modifiable facilement lorsque je passe en prod.

Bref, j'utilise la même technique pour le nom du serveur de la DB.

Quand j'aurai du temps (ou quand ma boite se décidera à me payer une formation .NET), je regarderai pour rassemble cela dans un seul fichier xml "hébergé" par la couche GUI mais qui serait accessible par toutes les couches de l'application.

Bon, voici peut-être une piste.

Résumons pour être bien d'accord, tu as une DLL avec son fichier de config, et tu souhaites lire les données de ce fichier de config concernant la dll.
Contrainte : l'exe, la dll et son fichier de config doivent être dans le même répertoire.

Le fichier de config de DLL nommé clSettings.dll.config

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

<?xml version="1.0" encoding="utf-8" ?> <configuration>   <appSettings> <add key="TestDll" value="test dll avec modif en prod"/> <add key="Test2" value=" valeur numéro 2, modif 2"/> <add key="Essai" value="Essai pour verif ; ok"/> </appSettings>   <configSections> <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="clSettings.My.MySettings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> </sectionGroup> </configSections>   </configuration>

---

Mise en place des lectures des settings dans le fichier de config
2 approches :
La DLL lit sa config
La DLL met a disposition le nom de son fichier de config

La dll clSettings.dll

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Imports System.Configuration   Public Class Class1 Public Property TestDLL As String Public Property Test2 As String Public Property Essai As String   ''' <summary>Lecture interne du fichier de config et alimentation des propriétées relatives aux settings</summary> Sub LitSettings() ' Alimentation des propriétés de la DLL par les settings du fichier de config Dim config = ConfigurationManager.OpenExeConfiguration(New Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath) Dim DllConfigAppSettings As AppSettingsSection = DirectCast(config.GetSection("appSettings"), AppSettingsSection)   TestDLL = DllConfigAppSettings.Settings("TestDLL").Value Test2 = DllConfigAppSettings.Settings("Test2").Value Essai = DllConfigAppSettings.Settings("Essai").Value   End Sub   ''' <summary>Fourni le nom du fichier de config de la DLL</summary> ''' <returns>Le nom du fichier de config de la DLL</returns> ''' <remarks>Au programme appelant d'effectuer les accés</remarks> Public Function GetAssemblyDLLFile() As String Return New Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath End Function   End Class

---

Utilisation

L'exe lit les propriétés que la DLL à mis à jour avec son fichier de config. (je conseillerai cette utilisation)

Code:

---

1 2 3 4 5 6 7 8

' lecture settings dll par propriété (settings lu par DLL dans son fichier de config) Private Sub btnLitSettingsDLL_Click(sender As System.Object, e As System.EventArgs) Handles btnLitSettingsDLL.Click Dim icl As clSettings.Class1 = New clSettings.Class1 icl.LitSettings() Label4.Text = icl.TestDLL Label5.Text = icl.Test2 Label6.Text = icl.Essai End Sub

---

L'exe obtient le nom du fichier de config de la dll et fait ses lectures

Code:

---

1 2 3 4 5 6 7 8 9 10

' lecture setting dll - direct avec le fichier config dll Private Sub btnDLLFileConfig_Click(sender As System.Object, e As System.EventArgs) Handles btnDLLFileConfig.Click Dim icl As clSettings.Class1 = New clSettings.Class1 Label16.Text = icl.GetAssemblyDLLFile Dim config = ConfigurationManager.OpenExeConfiguration(icl.GetAssemblyDLLFile) Dim DllConfigAppSettings As AppSettingsSection = DirectCast(config.GetSection("appSettings"), AppSettingsSection) Label15.Text = DllConfigAppSettings.Settings("TestDLL").Value Label16.Text = DllConfigAppSettings.Settings("Test2").Value Label17.Text = DllConfigAppSettings.Settings("Essai").Value End Sub

---

Espérant que cela t'aidera à avancer ;)

Bah déjà, merci de t'être penché sur le sujet.

Je testerai cela demain ou la semaine prochaine. Pour le moment, je me bats avec une connexion sftp (et c'est pas moi qui gagne :aie:)