Discussion :

[Kropernic]

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

Qu'en pensez-vous ?

[rv26t]

Bonjour,

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 ?

[Kropernic]

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.

[rv26t]

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 ?

[Kropernic]

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 :

  Sélectionner tout - Visualiser dans une fenêtre à part

  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 :

  Sélectionner tout - Visualiser dans une fenêtre à part

  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.

[Kropernic]

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.

[Sankasssss]

Bonjour,

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

[Kropernic]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[Kropernic]

Bonjour,

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

Utilisateur

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 ?

[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 ?

[Sankasssss]

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.

[Kropernic]

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.

[DotNetMatt]

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

[Sankasssss]

+1 DotNetMatt
On peut le voir avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath

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

[Kropernic]

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...

[Sankasssss]

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

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

qui contient :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

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>

[Kropernic]

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.

[Kropernic]

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 :

<?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...

[Kropernic]

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) :

<?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

<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

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 ^^.

[rv26t]

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

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.

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

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.

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.