Bonjour,
Je sais comment réaliser une lib dynamique de classes en .net (j'en ai
déjà fait plusieurs) mais je n'ai jamais vu comment réaliser une lib
static ? C'est possible ?
En fait quand je réalise une app .net je réutilise plusieurs de ces libs
et je trouve dommage d'avoir à distribuer à chaque fois une dizaines de
DLLs en plus de mon application. Surtout que l'application n'utilise pas
forcément toutes les classes dans chaque lib.
Gwenn
Bonjour,
Je sais comment réaliser une lib dynamique de classes en .net (j'en ai
déjà fait plusieurs) mais je n'ai jamais vu comment réaliser une lib
static ? C'est possible ?
En fait quand je réalise une app .net je réutilise plusieurs de ces libs
et je trouve dommage d'avoir à distribuer à chaque fois une dizaines de
DLLs en plus de mon application. Surtout que l'application n'utilise pas
forcément toutes les classes dans chaque lib.
Gwenn
Bonjour,
Je sais comment réaliser une lib dynamique de classes en .net (j'en ai
déjà fait plusieurs) mais je n'ai jamais vu comment réaliser une lib
static ? C'est possible ?
En fait quand je réalise une app .net je réutilise plusieurs de ces libs
et je trouve dommage d'avoir à distribuer à chaque fois une dizaines de
DLLs en plus de mon application. Surtout que l'application n'utilise pas
forcément toutes les classes dans chaque lib.
Gwenn
.NET n'a pas besoin de librairie statique.
Les assemblies, que vous confondez avec les librairies dynamiques,
remplacent avantageusement les deux types de librairies.
Les assemblies ont la souplesse et l'évolutivité des librairies dynamiques
grâce à leur chagement à la volée et la robustesse de librairies dynamique
grâce à la gestion très fines des versions lors de la compilation et de la
signature des assemblies.
Une assemblie utilitaire regroupera en ensemble de fonctionnalités connexes
qui seront intimement lié avec assez peu de fonctions inutilisées lors d'une
utilisation typique.
Les librairies statiques étaient un cauchemar pour la compatibilité
ascendante et les dépendances des options et des outils de linkages (entre
les versions de la C-runtime, le debug et release, avec les MFC en statique
ou en dynamique etc.).
Une conception soignée de la migration de vos librairies statiques en un
ensemble d'assemblies serait une bonne résolution.
.NET, Windows Installer, les "Application Blocks" etc... permettent de gérer
et de faire migrer très facilement un ensemble conséquent d'assemnlie
utilitaire.
Je ne vois pas de cas de figure où une librairie statique soit plus
avantageuse qu'un ensemble bien conçu d'assemblies.
.NET n'a pas besoin de librairie statique.
Les assemblies, que vous confondez avec les librairies dynamiques,
remplacent avantageusement les deux types de librairies.
Les assemblies ont la souplesse et l'évolutivité des librairies dynamiques
grâce à leur chagement à la volée et la robustesse de librairies dynamique
grâce à la gestion très fines des versions lors de la compilation et de la
signature des assemblies.
Une assemblie utilitaire regroupera en ensemble de fonctionnalités connexes
qui seront intimement lié avec assez peu de fonctions inutilisées lors d'une
utilisation typique.
Les librairies statiques étaient un cauchemar pour la compatibilité
ascendante et les dépendances des options et des outils de linkages (entre
les versions de la C-runtime, le debug et release, avec les MFC en statique
ou en dynamique etc.).
Une conception soignée de la migration de vos librairies statiques en un
ensemble d'assemblies serait une bonne résolution.
.NET, Windows Installer, les "Application Blocks" etc... permettent de gérer
et de faire migrer très facilement un ensemble conséquent d'assemnlie
utilitaire.
Je ne vois pas de cas de figure où une librairie statique soit plus
avantageuse qu'un ensemble bien conçu d'assemblies.
.NET n'a pas besoin de librairie statique.
Les assemblies, que vous confondez avec les librairies dynamiques,
remplacent avantageusement les deux types de librairies.
Les assemblies ont la souplesse et l'évolutivité des librairies dynamiques
grâce à leur chagement à la volée et la robustesse de librairies dynamique
grâce à la gestion très fines des versions lors de la compilation et de la
signature des assemblies.
Une assemblie utilitaire regroupera en ensemble de fonctionnalités connexes
qui seront intimement lié avec assez peu de fonctions inutilisées lors d'une
utilisation typique.
Les librairies statiques étaient un cauchemar pour la compatibilité
ascendante et les dépendances des options et des outils de linkages (entre
les versions de la C-runtime, le debug et release, avec les MFC en statique
ou en dynamique etc.).
Une conception soignée de la migration de vos librairies statiques en un
ensemble d'assemblies serait une bonne résolution.
.NET, Windows Installer, les "Application Blocks" etc... permettent de gérer
et de faire migrer très facilement un ensemble conséquent d'assemnlie
utilitaire.
Je ne vois pas de cas de figure où une librairie statique soit plus
avantageuse qu'un ensemble bien conçu d'assemblies.
Paul Bacelar wrote:.NET n'a pas besoin de librairie statique.
Les assemblies, que vous confondez avec les librairies dynamiques,
remplacent avantageusement les deux types de librairies.
Non je savais bien que c'est différent de l'ancienne notion de librairie
dynamique. J'ai juste utilisé le mot "dynamique" pour souligner que les
assemblies étaient chargés dynamiquement au lancement du programme.
Les assemblies ont la souplesse et l'évolutivité des librairies
dynamiques
grâce à leur chagement à la volée et la robustesse de librairies
dynamique
grâce à la gestion très fines des versions lors de la compilation et de
la
signature des assemblies.
Oui oui !
Une assemblie utilitaire regroupera en ensemble de fonctionnalités
connexes
qui seront intimement lié avec assez peu de fonctions inutilisées lors
d'une
utilisation typique.
Mais justement non ! Je m'explique ci-après ...
Les librairies statiques étaient un cauchemar pour la compatibilité
ascendante et les dépendances des options et des outils de linkages
(entre
les versions de la C-runtime, le debug et release, avec les MFC en
statique
ou en dynamique etc.).
Je sais bien.
Une conception soignée de la migration de vos librairies statiques en un
ensemble d'assemblies serait une bonne résolution.
Non mais je ne veux rien migrer ! Comme je disais dans le message
précédent j'ai déjà de nombreux assemblies utilitaires, conçus
correctement je pense, c'est juste leur utilisation qui me pose un
"problème".
.NET, Windows Installer, les "Application Blocks" etc... permettent de
gérer
et de faire migrer très facilement un ensemble conséquent d'assemnlie
utilitaire.
Je ne vois pas de cas de figure où une librairie statique soit plus
avantageuse qu'un ensemble bien conçu d'assemblies.
Nous y voici.
J'ai de nombreuses assemblies utilitaires, style :
GwennBrogniart.Collections.dll
GwennBrogniart.Communications.dll
GwennBrogniart.Neural.SNN.dll
etc. etc.
bien décomposés, un peu comme .NET framework.
Ces assemblies me sont très utiles donc dès que je commence une nouvelle
app je me retrouve rapidement à en réutiliser plusieurs.
Et c'est là où cela m'ennuie, je ne trouve pas forcément très élégant de :
1. distribuer une application avec 5-6 (voire plus) de DLLs
(assemblies utilitaires) à coté.
2. distribuer une assemblie utilitaire à coté de mon application alors
que je ne me sers pas forcément de toutes les classes dedans pour ce
programme.
C'est là où les anciennes libs statiques avaient tout leur avantage :
pour les _petits_ programmes on pouvait distribuer un seul exécutable et
le Linker n'incluait dans l'exécutable que les seules portions de
codes utilisées de la (les) lib(s) statique(s).
Note : Les deux points 1. et 2. sont évidemment opposés et c'est là le
problème. Si je fragmente encore plus mes assemblies je vais me
retrouver avec potentiellement encore plus de DLLs utilitaires à
distribuer à coté d'un programme donné. Et inversement si je regroupe,
des portions "massives" (relativement...) de code risquent d'être
inutilisées.
Oh mais j'ai bien sûr conscience qu'une assemblie utilitaire, grâce au
MSIL et à l'utilisation importante du .NET framework par le code qui la
compose, donne un fichier de petite taille donc on peut relativiser ce
qui est inutilisé si on parle en "octets".
Mais c'est philosophiquement que cela me gène, et pourtant je ne suis
pas du genre à être tatillon d'habitude, vraiment pas. Au contraire
j'essaye justement souvent de faire entendre raison à des gens qui
veulent gagner des Ko par ci ou par là, sans véritable raison.
Par exemple je trouve dommage d'avoir à mettre une assemblie de mon cru
"collections" comportant une quinzaine de classes quand le programme ne
se sert que d'une seule. Un gros framework (.net) peut se le permettre
car il est installé *presque en standard* sur les machines et surtout
une seule copie sert à de nombreux programmes. En revanche un
developpeur lambda devra inclure les assemblies utilitaires dont le
programme a besoin pour CHAQUE logiciel qu'il veut distribuer.
Voilà. Bien sûr le chargement dynamique (que ça soit l'ancien ou
maintenant les assemblies) est très utile dans de nombreux cas et
possède beaucoup de qualités. Mais parfois il peut être intéressant de
linker en statique juste des petites choses plutot que d'inclure une
"grosse" (relativement...) lib/assemblie à coté.
Mais bon, cela n'est donc pas possible. Je pense donc que je vais faire
attention, _quand cela est possible sans nuire à la clarté et propreté
du code, de l'architecture, de l'assemblie_, à ne pas trop fragmenter
mes assemblies utilitaires. Et au diable les classes inutilisées.
Merci bien pour cette (première?) réponse en tout cas.
Gwenn
Paul Bacelar wrote:
.NET n'a pas besoin de librairie statique.
Les assemblies, que vous confondez avec les librairies dynamiques,
remplacent avantageusement les deux types de librairies.
Non je savais bien que c'est différent de l'ancienne notion de librairie
dynamique. J'ai juste utilisé le mot "dynamique" pour souligner que les
assemblies étaient chargés dynamiquement au lancement du programme.
Les assemblies ont la souplesse et l'évolutivité des librairies
dynamiques
grâce à leur chagement à la volée et la robustesse de librairies
dynamique
grâce à la gestion très fines des versions lors de la compilation et de
la
signature des assemblies.
Oui oui !
Une assemblie utilitaire regroupera en ensemble de fonctionnalités
connexes
qui seront intimement lié avec assez peu de fonctions inutilisées lors
d'une
utilisation typique.
Mais justement non ! Je m'explique ci-après ...
Les librairies statiques étaient un cauchemar pour la compatibilité
ascendante et les dépendances des options et des outils de linkages
(entre
les versions de la C-runtime, le debug et release, avec les MFC en
statique
ou en dynamique etc.).
Je sais bien.
Une conception soignée de la migration de vos librairies statiques en un
ensemble d'assemblies serait une bonne résolution.
Non mais je ne veux rien migrer ! Comme je disais dans le message
précédent j'ai déjà de nombreux assemblies utilitaires, conçus
correctement je pense, c'est juste leur utilisation qui me pose un
"problème".
.NET, Windows Installer, les "Application Blocks" etc... permettent de
gérer
et de faire migrer très facilement un ensemble conséquent d'assemnlie
utilitaire.
Je ne vois pas de cas de figure où une librairie statique soit plus
avantageuse qu'un ensemble bien conçu d'assemblies.
Nous y voici.
J'ai de nombreuses assemblies utilitaires, style :
GwennBrogniart.Collections.dll
GwennBrogniart.Communications.dll
GwennBrogniart.Neural.SNN.dll
etc. etc.
bien décomposés, un peu comme .NET framework.
Ces assemblies me sont très utiles donc dès que je commence une nouvelle
app je me retrouve rapidement à en réutiliser plusieurs.
Et c'est là où cela m'ennuie, je ne trouve pas forcément très élégant de :
1. distribuer une application avec 5-6 (voire plus) de DLLs
(assemblies utilitaires) à coté.
2. distribuer une assemblie utilitaire à coté de mon application alors
que je ne me sers pas forcément de toutes les classes dedans pour ce
programme.
C'est là où les anciennes libs statiques avaient tout leur avantage :
pour les _petits_ programmes on pouvait distribuer un seul exécutable et
le Linker n'incluait dans l'exécutable que les seules portions de
codes utilisées de la (les) lib(s) statique(s).
Note : Les deux points 1. et 2. sont évidemment opposés et c'est là le
problème. Si je fragmente encore plus mes assemblies je vais me
retrouver avec potentiellement encore plus de DLLs utilitaires à
distribuer à coté d'un programme donné. Et inversement si je regroupe,
des portions "massives" (relativement...) de code risquent d'être
inutilisées.
Oh mais j'ai bien sûr conscience qu'une assemblie utilitaire, grâce au
MSIL et à l'utilisation importante du .NET framework par le code qui la
compose, donne un fichier de petite taille donc on peut relativiser ce
qui est inutilisé si on parle en "octets".
Mais c'est philosophiquement que cela me gène, et pourtant je ne suis
pas du genre à être tatillon d'habitude, vraiment pas. Au contraire
j'essaye justement souvent de faire entendre raison à des gens qui
veulent gagner des Ko par ci ou par là, sans véritable raison.
Par exemple je trouve dommage d'avoir à mettre une assemblie de mon cru
"collections" comportant une quinzaine de classes quand le programme ne
se sert que d'une seule. Un gros framework (.net) peut se le permettre
car il est installé *presque en standard* sur les machines et surtout
une seule copie sert à de nombreux programmes. En revanche un
developpeur lambda devra inclure les assemblies utilitaires dont le
programme a besoin pour CHAQUE logiciel qu'il veut distribuer.
Voilà. Bien sûr le chargement dynamique (que ça soit l'ancien ou
maintenant les assemblies) est très utile dans de nombreux cas et
possède beaucoup de qualités. Mais parfois il peut être intéressant de
linker en statique juste des petites choses plutot que d'inclure une
"grosse" (relativement...) lib/assemblie à coté.
Mais bon, cela n'est donc pas possible. Je pense donc que je vais faire
attention, _quand cela est possible sans nuire à la clarté et propreté
du code, de l'architecture, de l'assemblie_, à ne pas trop fragmenter
mes assemblies utilitaires. Et au diable les classes inutilisées.
Merci bien pour cette (première?) réponse en tout cas.
Gwenn
Paul Bacelar wrote:.NET n'a pas besoin de librairie statique.
Les assemblies, que vous confondez avec les librairies dynamiques,
remplacent avantageusement les deux types de librairies.
Non je savais bien que c'est différent de l'ancienne notion de librairie
dynamique. J'ai juste utilisé le mot "dynamique" pour souligner que les
assemblies étaient chargés dynamiquement au lancement du programme.
Les assemblies ont la souplesse et l'évolutivité des librairies
dynamiques
grâce à leur chagement à la volée et la robustesse de librairies
dynamique
grâce à la gestion très fines des versions lors de la compilation et de
la
signature des assemblies.
Oui oui !
Une assemblie utilitaire regroupera en ensemble de fonctionnalités
connexes
qui seront intimement lié avec assez peu de fonctions inutilisées lors
d'une
utilisation typique.
Mais justement non ! Je m'explique ci-après ...
Les librairies statiques étaient un cauchemar pour la compatibilité
ascendante et les dépendances des options et des outils de linkages
(entre
les versions de la C-runtime, le debug et release, avec les MFC en
statique
ou en dynamique etc.).
Je sais bien.
Une conception soignée de la migration de vos librairies statiques en un
ensemble d'assemblies serait une bonne résolution.
Non mais je ne veux rien migrer ! Comme je disais dans le message
précédent j'ai déjà de nombreux assemblies utilitaires, conçus
correctement je pense, c'est juste leur utilisation qui me pose un
"problème".
.NET, Windows Installer, les "Application Blocks" etc... permettent de
gérer
et de faire migrer très facilement un ensemble conséquent d'assemnlie
utilitaire.
Je ne vois pas de cas de figure où une librairie statique soit plus
avantageuse qu'un ensemble bien conçu d'assemblies.
Nous y voici.
J'ai de nombreuses assemblies utilitaires, style :
GwennBrogniart.Collections.dll
GwennBrogniart.Communications.dll
GwennBrogniart.Neural.SNN.dll
etc. etc.
bien décomposés, un peu comme .NET framework.
Ces assemblies me sont très utiles donc dès que je commence une nouvelle
app je me retrouve rapidement à en réutiliser plusieurs.
Et c'est là où cela m'ennuie, je ne trouve pas forcément très élégant de :
1. distribuer une application avec 5-6 (voire plus) de DLLs
(assemblies utilitaires) à coté.
2. distribuer une assemblie utilitaire à coté de mon application alors
que je ne me sers pas forcément de toutes les classes dedans pour ce
programme.
C'est là où les anciennes libs statiques avaient tout leur avantage :
pour les _petits_ programmes on pouvait distribuer un seul exécutable et
le Linker n'incluait dans l'exécutable que les seules portions de
codes utilisées de la (les) lib(s) statique(s).
Note : Les deux points 1. et 2. sont évidemment opposés et c'est là le
problème. Si je fragmente encore plus mes assemblies je vais me
retrouver avec potentiellement encore plus de DLLs utilitaires à
distribuer à coté d'un programme donné. Et inversement si je regroupe,
des portions "massives" (relativement...) de code risquent d'être
inutilisées.
Oh mais j'ai bien sûr conscience qu'une assemblie utilitaire, grâce au
MSIL et à l'utilisation importante du .NET framework par le code qui la
compose, donne un fichier de petite taille donc on peut relativiser ce
qui est inutilisé si on parle en "octets".
Mais c'est philosophiquement que cela me gène, et pourtant je ne suis
pas du genre à être tatillon d'habitude, vraiment pas. Au contraire
j'essaye justement souvent de faire entendre raison à des gens qui
veulent gagner des Ko par ci ou par là, sans véritable raison.
Par exemple je trouve dommage d'avoir à mettre une assemblie de mon cru
"collections" comportant une quinzaine de classes quand le programme ne
se sert que d'une seule. Un gros framework (.net) peut se le permettre
car il est installé *presque en standard* sur les machines et surtout
une seule copie sert à de nombreux programmes. En revanche un
developpeur lambda devra inclure les assemblies utilitaires dont le
programme a besoin pour CHAQUE logiciel qu'il veut distribuer.
Voilà. Bien sûr le chargement dynamique (que ça soit l'ancien ou
maintenant les assemblies) est très utile dans de nombreux cas et
possède beaucoup de qualités. Mais parfois il peut être intéressant de
linker en statique juste des petites choses plutot que d'inclure une
"grosse" (relativement...) lib/assemblie à coté.
Mais bon, cela n'est donc pas possible. Je pense donc que je vais faire
attention, _quand cela est possible sans nuire à la clarté et propreté
du code, de l'architecture, de l'assemblie_, à ne pas trop fragmenter
mes assemblies utilitaires. Et au diable les classes inutilisées.
Merci bien pour cette (première?) réponse en tout cas.
Gwenn
Bonjour,
On ne peut en effet pas faire de link statique tel que tu l'entends.
Une assembly est une unité de déploiement.
La solution pour répondre à ton besoin consisterai à inclure les classes
nécessaires dans ton projet a chaque fois que tu en as besoin.
Ainsi tu ne redistribuerait pas l'assembly mais le code au design.
Le GROS inconvénient de cette technique est que tu "dupliques" le code.
Il y
pourrait y avoir un moyen d'inclure les classes à partir d'un référentiel,
pour permettre de propager les modifications.
On s'écarte beaucoup du mode de fonctionnement de .NET.
Distribuer "beaucoup" on des "grosses" assemblies pose juste le problème de
la taille du déploiement.
Au Runtime, le résultat est le meme : ne sont chargées que les classes
utilisées.
Petit éclairage utile j'espere.
Bonjour,
On ne peut en effet pas faire de link statique tel que tu l'entends.
Une assembly est une unité de déploiement.
La solution pour répondre à ton besoin consisterai à inclure les classes
nécessaires dans ton projet a chaque fois que tu en as besoin.
Ainsi tu ne redistribuerait pas l'assembly mais le code au design.
Le GROS inconvénient de cette technique est que tu "dupliques" le code.
Il y
pourrait y avoir un moyen d'inclure les classes à partir d'un référentiel,
pour permettre de propager les modifications.
On s'écarte beaucoup du mode de fonctionnement de .NET.
Distribuer "beaucoup" on des "grosses" assemblies pose juste le problème de
la taille du déploiement.
Au Runtime, le résultat est le meme : ne sont chargées que les classes
utilisées.
Petit éclairage utile j'espere.
Bonjour,
On ne peut en effet pas faire de link statique tel que tu l'entends.
Une assembly est une unité de déploiement.
La solution pour répondre à ton besoin consisterai à inclure les classes
nécessaires dans ton projet a chaque fois que tu en as besoin.
Ainsi tu ne redistribuerait pas l'assembly mais le code au design.
Le GROS inconvénient de cette technique est que tu "dupliques" le code.
Il y
pourrait y avoir un moyen d'inclure les classes à partir d'un référentiel,
pour permettre de propager les modifications.
On s'écarte beaucoup du mode de fonctionnement de .NET.
Distribuer "beaucoup" on des "grosses" assemblies pose juste le problème de
la taille du déploiement.
Au Runtime, le résultat est le meme : ne sont chargées que les classes
utilisées.
Petit éclairage utile j'espere.
