Discussion :

[CodeMan]

Bonjour,
J'ai développé une bibliothèque d'export de données en utilisant le langage C# sous l'environnement .NET.
J'ai généré le DLL de ma bibliothèque et il fonctionne comme il faut.
Pour utiliser ma bibliothèque dans un autre projet je doit référencer le DLL, créer un bouton dans la fenêtre MDI principale et ajouter le code d'appel de la fonction d'export.

J'ai a poser 2 questions principaux :

- Je veut rendre l'intégration de mon DLL plus facile dans les autres projets, pour cela je veut créer un composant dans la barre d'outils Toolbox qui avec un simple glisser/déplacer permet d'ajouter le bouton et le code d'appel a la fenêtre. comme pour n'importe quel autre composant.

- Ma bibliothèque est développée avec C#, est ce possible de l'utiliser dans d'autres projets C++ et VB .NET même si dans mon code j'utilise des types que je connais dans C# comme IContainer.

Merci pour votre aide.

[harz62]

Bonjour,
- Je veut rendre l'intégration de mon DLL plus facile dans les autres projets

Si tu veux ta dll dans d'autres projets, enregistre la dans le GAC, ça évitera de dupliquer plusieurs fois le fichier.

- Ma bibliothèque est développée avec C#, est ce possible de l'utiliser dans d'autres projets C++ et VB .NET même si dans mon code j'utilise des types que je connais dans C# comme IContainer.

Si ta DLL est compatible CLS alors elle peut être manipulée facilement par n'importe quel langage managé. Utilise l'attribut CLSCompliant pour avoir la meilleure compatibilité.

[CodeMan]

Merci harz62 pour vos réponses,

pouvez vous m'expliquer c'est quoi le GAC, c'est la première fois que j'entend parler de sa
et est ce que sa permet d'ajouter mon composant dans la Toolbox .NET ? c'est ce que je souhaite faire.

et comment utiliser le CLSCompliant ?

merci encore une fois pour votre aide.

[Philippe Vialatte]

Si tu veux ta dll dans d'autres projets, enregistre la dans le GAC, ça évitera de dupliquer plusieurs fois le fichier.

Mouais...a discuter, perso, je conseille plutot de conserver les references aux dll dans des dossiers, contenus ou non dans la solution, mais dans tous les cas dans le contrôleur de code source...

[CodeMan]

mais dans tous les cas dans le contrôleur de code source...

désolé mais je comprend pas ce que vous voulez dire par sa

[ArianeV]

Pour répondre à ta question, la GAC (grossièrement), c'est un composant Windows qui référence toutes les dlls disponibles sur le système (avec leur nom, leur emplacement, leur version etc...)

Si ta dll est enregistrée dans la GAC, tu dois quand meme y faire référence dans tes projets, mais elle apparait dans les dll windows, tu n'as plus à faire parcourir pour la localiser sur ton disque dur (ce qui est quand meme pratique).

Par contre, ca ne résout pas ton problème : il faut quand y faire référence.

Honnetement, je ne sais pas si ce que tu veux faire est possible, j'ai peur que tu doives y faire référence systématiquement...

Bonne journée

[pequatre]

je veut créer un composant dans la barre d'outils Toolbox qui avec un simple glisser/déplacer permet d'ajouter le bouton et le code d'appel a la fenêtre. comme pour n'importe quel autre composant.
Merci pour votre aide.

salut. je suis sous VS2003 donc ça marchera peut-etre pas pour toi:

je suppose que tu es en train de construire un formulaire et que tu veux utiliser ton bouton dedans. T'es en mode Design, tu affiches la boite à outils, tu affiches la section "Mes controles utilisateur", tu cliques droit dedans --> "ajouter/supprimer des éléments", une fenêtre "personnaliser la boite à outils" s'ouvre, tu rajoutes ta dll à la liste (bouton "parcourir" ) tu fais OK et ton controle perso doit maintenant apparaître dans la barre d'outils.
voir aussi http://msdn.microsoft.com/en-us/libr...6x(VS.80).aspx

je m'en rends compte, j'ai utilisé cette technique pour une classe que j'ai créée qui héritait d'un WinForm (TreeView en l'occurrence). je ne sais pas si ça marchera dans les autres cas.

bon courage.

[dev01]

Mouais...a discuter, perso, je conseille plutot de conserver les references aux dll dans des dossiers, contenus ou non dans la solution, mais dans tous les cas dans le contrôleur de code source...

MS nous pond le Global Assembly Cache (GAC) pour éviter les situations "d'enfer des dll" ( en gros c'est la situation ou on a deux app utilisant chacune la lib SuperLib.dll mais l'app A utilise la version 1 et l'App B utilise la version 2. Jusque la tout va bien mais le problème surgit quand chaque installeur de chaque app enregistre la lib dans C:\WIndows\System32\ (comme ça on a pas de pb de localisation ... :-( ) ). Forcément vous comprenez le pb. Si vous installé l'app A puis l'app B vous avez l'app B qui fonction, mais pas l'app A et si vous reinstallez l'app A ben c'est l'app B qui fonctionne plus).
De plus l'utilisation du GAC permet également d'éviter de se retrouver avec 30 fois la même lib dans 30 répertoires différents .... D'ou un gain de place forcément.

Quand j'entend dire que "Moi j'utilise pas le GAC je fait des xcopy de mes lib parce que d'abord ..." Au fait d'abord quoi ? Pourquoi ne pas utiliser le gac ? qu'est ce qui te déranges dans le gac pvialatte ?

Bref le gac est une partie de la solution dans le cas de la question posée, la fin de la réponse est à chercher du coté de l'héritage par le composant de la classe ... System.ComponentModel.Component

[Philippe Vialatte]

De plus l'utilisation du GAC permet également d'éviter de se retrouver avec 30 fois la même lib dans 30 répertoires différents .... D'ou un gain de place forcément.

Ca, c'est un "faux" probleme, a moins que ta dll fasse 50 mo, 30 fois la meme lib, ca fait pas peur a un disque dur de 160 Go... et si ta dll fait 50 mo, il y'a probablement un pb qq part avec ta facon de la faire

Quand j'entend dire que "Moi j'utilise pas le GAC je fait des xcopy de mes lib parce que d'abord ..." Au fait d'abord quoi ? Pourquoi ne pas utiliser le gac ? qu'est ce qui te déranges dans le gac pvialatte ?

deployer dans le gac, c'est bien...

Mais une solution, ca doit etre atomique par definition...ou sinon, j'ai manque qq chose...si c'est pas atomique, tu vas toujours te trouver a un moment ou tes builds vont peter parce que un des dev du projet a oublie de dire qu'il a mis a jour la dll dans le GAC de ca machine
It works on my machine !!!

Si tu regardes a long terme, mettre une assembly dans le GAC, ca doit pas etre "tiens, j'ai deux projets, comment je fais pour avoir la meme dll", ca doit etre un service que tu vas maintenir pendant une duree, c'est pas non plus une decision a prendre a la legere , si tu mets une assembly dans le gac, corrige moi si je me trompe, mais tu dois aussi mettre ses dependances, et gerer la compatibilite sur chaque version...

Apres, une fois en prod, 200% d'accord, le GAC, c'est bien

[dev01]

Ca, c'est un "faux" probleme, a moins que ta dll fasse 50 mo, 30 fois la meme lib, ca fait pas peur a un disque dur de 160 Go... et si ta dll fait 50 mo, il y'a probablement un pb qq part avec ta facon de la faire

Ouais ou pas. Par définition je hais les doublons, tout le monde n'a pas un disque de 160 Go, tout le monde n'aime pas gacher de l'espace disque ....

deployer dans le gac, c'est bien...

on est d'accord

Si tu regardes a long terme, mettre une assembly dans le GAC, ca doit pas etre "tiens, j'ai deux projets, comment je fais pour avoir la meme dll", ca doit etre un service que tu vas maintenir pendant une duree,

Ben si t'as dll est partagé entre deux app, alors c'est un service

c'est pas non plus une decision a prendre a la legere , si tu mets une assembly dans le gac, corrige moi si je me trompe, mais tu dois aussi mettre ses dependances,

En toute logique oui

et gerer la compatibilite sur chaque version...

Si le versionning est bien fait le gac se charge de tout. En effet dans le gac la version 1.0.1 et la version 1.1.0 sont installés en cote à cote et les app demande le chargement de la version avec laquelle elles ont été liés.

Apres, une fois en prod, 200% d'accord, le GAC, c'est bien

Ok alors je comprend mieux ton point de vue. Je parlais effectivement principalement de la situation en production, et pendant les phases de tests sur sur machine. La situation en temps de dev est un peu plus compliquer effectivement

[Philippe Vialatte]

Si le versionning est bien fait

ca fait un gros si, ca