Discussion :

[Franck.H]

Je souhaite, au fil de mes développements, créer des bibliothèques réutilisables. Je suis un peu emmêlé entre DLL et espace de noms, je n'ai pas pour habitude de faire ça en VB donc si quelqu'un peut me démêler tout ça, ça serait sympa.

Est-ce que lorsque je créer une hiérarchie d'espace de noms il faut que les répertoires sur le disque soit identiques (comme j'ai pu le voir sur un langage mais je ne me souviens plus le quel) ?

Est-il possible de faire des imports directement depuis des sources réutilisables ou bien on ne peut passer que par des DLL à référencer puis utiliser l'espace de noms qui en découle ?

Bref, dites-moi tout

[_Ez3kiel]

Je peux t'apporter mes maigres connaissances, même si je pense que d'autres sauront mieux te répondre que moi.

Est-ce que lorsque je créer une hiérarchie d'espace de noms il faut que les répertoires sur le disque soit identiques (comme j'ai pu le voir sur un langage mais je ne me souviens plus le quel) ?

Non, lorsque tu fais tes NameSpaces, si tu ne les places pas dans des "dossiers" VS, par défaut toutes tes classes seront -au niveau du disque- à la racine de ton projet.

Lorsque tu crées ta hiérarchie avec des namespace dans ton bibliothèque, et que tu places ces classes dans des "dossiers" de Visual Studio (Dossier que tu peux ajouter avec Click Droit dans VS) le compilateur génère la même arborescence en dossier et y place les class.vb dans les dossiers correspondants.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Namespace UI
    Namespace UI.controls
        Public Class TxtBox
 
        End Class
    End Namespace
    Namespace UI.eventHandler
        Public Class TxtBoxEventHandler
 
        End Class
    End Namespace
    Namespace UI.Interface
        Public Class ITxtBox
 
        End Class
    End Namespace
End Namespace

Après compilation, si tu as placé chacune des classes dans un dossier(VS), sur le disque dans ton dossier de projet, tu auras un dossier UI, qui contient 3 dossier (Controls, EventHandler,Interface), et respectivement chacun contiendra un fichier TxtBox.Vb, TxtBoxEventHandler.Vb, ItxtBox.Vb.

MAIS, tu ne dois cela qu'aux dossiers(VS) que tu as mis. Le namespace en lui même ne crée pas les dossiers sur le disque.

Est-il possible de faire des imports directement depuis des sources réutilisables ou bien on ne peut passer que par des DLL à référencer puis utiliser l'espace de noms qui en découle ?

Je ne suis pas sûr de bien saisir la question ...
Depuis VS2012 (2010 je ne sais pas trop), tu peux lier 2 projets, donc par exemple, un prototype d'application, et le projet de ta bibliothèque, tu as ainsi accès aux sources, aux débogages pas à pas dans ton bibliothèque, etc lorsque tu appelles une fonction de la bibliothèque dans ton prototype.
Et bien sûr tu peux également référencer la .dll et faire un imports sans avoir à lier les 2 projets. Mais tu n'auras pas accès au code source directement depuis ton prototype.

Voilà en espérant avoir pu t'aiguiller un peu malgré les explications fouillies ...

[AsPrO]

Est-il possible de faire des imports directement depuis des sources réutilisables ou bien on ne peut passer que par des DLL à référencer puis utiliser l'espace de noms qui en découle ?

Si je comprends bien la question, soit tu laisses ton code ouvert et donc il te suffira d'ajouter le projet à ta solution, soit tu "fermes" ton code en générant une librairie (.dll) que tu ajouteras en référence. ( Il y a aussi une possibilité d'utiliser des objets com mais je ne connais pas trop)


J'ajouterai que tu n'es pas obligé de suivre l'arborescence des dossiers dans les namespace mais tu t'y trouveras quand même plus facilement si tu t'en rapproches ;-)

[Pol63]

(pas lu les réponses qui sont peut etre déjà suffisantes)

un namespace est un "dossier" pour ranger des classes
l'utilisation des namespace est juste sur l'intellisense (auto complétion)

par défaut il y a d'ailleurs un namespace par défaut sur un projet

dans un projet on peut faire des dossiers pour ranger les fichiers, mais ca n'est pas lié aux namespace, c'est pour s'y retrouver dans les fichiers du projet
les namespace c'est pour s'y retrouver pendant qu'on code

le mot clé imports ne sert qu'à ne pas préfixer
dim b as system.Drawing.Bitmap
peut s'écrire
dim b as bitmap
si on a imports system.Drawing

cela ne dispense pas d'avoir une référence sur system.Drawing.dll


si tu veux un noyau réutilisable dans plusieurs projets (c'est souvent le cas quand on fait plusieurs projets) il y a plusieurs moyens
soit tu fais un projet dll, et tu copies ensuite la dll dans les projets où tu veux l'utiliser
tu peux copier par dessus les anciens fichiers et les exe utiliseront la nouvelle dll sans poser de question

il y a aussi des référence de projet, c'est à dire référencer un autre projet de la solution (une solution .sln étant un regroupement de plusieurs projets)
concretement une fois ton code source dans un endroit x de ton disque dur, tu peux depuis une solution autre faire "ajouter un projet", et ouvrir le vbproj de la dll
les 2 codes sources seront disponibles et modifiables
à la compilation, la dll sera compilée en 1er la copiée automatiquement dans le dossier bin\debug(/release) de l'exe de la solution ayant une référence de type projet

j'imagine donc qu'on doit pouvoir avoir plusieurs solutions ayant la même dll ouverte, les modifications seront donc pour tout le monde

l'avantage d'avoir le code source de la dll à côté c'est de pouvoir débugger plus facilement quand un problème vient de celle ci
bien qu'avec les pdb tu peux aussi débugger sans avoir le code source d'ouvert

[tomlev]

En résumé :
- les namespaces correspondent à une organisation "logique" du code
- les assemblies (dll ou exe) correspondent à une organisation "physique" du code
- ces deux modes d'organisation sont orthogonaux ; des classes d'un même namespace peuvent se trouver dans différents assemblies, et un assembly peut contenir des classes de différents namespaces

Il n'y a pas de contrainte technique concernant l'arborescence des dossiers, mais en pratique on essaie généralement de la faire correspondre avec l'arborescence des namespaces.

[Franck.H]

...mais en pratique on essaie généralement de la faire correspondre avec l'arborescence des namespaces.

C'est ce que je fait finalement et j'ai opté pour des DLL mais je vais voir avec mon chef ce qu'il préfère car ça va quand même servir à plusieurs programmeurs, c'est pour ça que je voulais des informations précises à ce sujet.

Merci à tous pour vos éclaircissement, je pense avoir toutes les infos