Avantages de l'utilisation de fichiers .dll par rapport à la liaison de fichiers .cs à des projets (pour mes propres classes d'assistance génériques / méthodes d'extension)
J'ai un projet d'aide que j'utilise dans toutes les applications que je crée. Il contient des méthodes d'extension et un tas de classes d'assistance génériques, de contrôles, etc. Je mets à jour/étends le projet d'aide de temps en temps. Ce sont généralement de petits projets sans rapport avec eux, et je suis la seule personne à travailler sur chacun d'eux.
J'ai essayé deux approches pour l'utiliser
- ajouter des fichiers .cs directement (Ajouter comme lien) à chaque projet où je les utilise
- compilez-le comme .dll et ajoutez-le comme référence
Je vois certains avantages et inconvénients de ces approches.
Le premier:
- est plus simple, car les classes d'assistance sont compilées dans le fichier exe, donc je peux souvent très facilement fournir un seul fichier .exe qui fonctionnera très bien. Parce que j'ajoute en tant que lien, je peux être sûr que chaque fois que je crée un projet qui utilise l'aide, les fichiers d'aide seront la dernière version.
- est encore plus simple, car je peux séparer les fichiers, afin que mes méthodes d'extension qui fonctionnent correctement sur .NET 4.0 puissent être référencées séparément de celles qui nécessitent .NET 4.5, ce qui signifie que l'application dans son ensemble peut s'exécuter sur .NET 4.0
- Permet de déboguer à travers le code, avec tous les avantages des points d'arrêt etc etc ...
- ne semble pas être la "meilleure pratique"
Le deuxième:
- semble être la bonne approche, mais:
- m'oblige à fournir un fichier .dll distinct, ce qui, pour une raison quelconque, est beaucoup plus difficile pour les utilisateurs (ils ont tendance à partager mes programmes sans le .dll, qui se bloque ensuite au démarrage)
- car il est compilé en un seul .dll, il nécessitera la version la plus élevée de .NET - beaucoup de mes utilisateurs n'ont pas .NET 4.5 et seuls certains éléments de ma classe d'assistance l'exigent, ce qui signifie que je peux forcer certaines personnes de mettre à jour leurs systèmes sans raison
- Je dois également m'assurer que chaque fois que je mets à jour l'un de mes programmes, je fournis également le fichier .dll - même si je ne sais pas s'il a été modifié depuis la dernière version, ou non (il aurait pu l'être, mais il pourrait aussi bien être la même version). Je ne peux pas voir un moyen simple de déterminer cela, sans garder la trace de la version de l'Assemblée, qui est un travail supplémentaire. Pour l'instant, lorsque je mets à jour mes programmes, je ne livre que des exe mis à jour, et j'aime les garder petits et discrets.
Alors, quel est l'avantage réel d'utiliser le fichier .dll ici? Veuillez noter que je suis la seule personne à modifier le code de toutes les applications et des fichiers d'assistance.
Aussi, pour clarifier - les applications sont généralement très peu nombreuses, alors que le code contenu dans les classes d'assistance est complètement générique pour chacune d'entre elles (quelques simples comparaisons de chaînes, chemins ou opérations XML, etc.)
En fait, quelqu'un m'a fait réaliser tout à l'heure qu'il y avait une troisième option. Comme j'ai le code d'aide dans un projet séparé, je peux ajouter ce projet aux solutions de chacune de mes applications distinctes - ce qui fonctionne un peu comme `` Ajouter en tant que lien '' pour des fichiers uniques, sauf que je n'ajoute qu'un seul projet ... Mais comme l'a remarqué Doc Brown, cela signifie essentiellement que .dll devra être ajouté au projet de toute façon ...
Encore une autre chose qui est en quelque sorte en faveur de ne pas utiliser les fichiers dll est la possibilité de déboguer activement via la classe d'assistance ...
Vous avez déjà repéré la plupart des avantages et des inconvénients. L'utilisation de fichiers cs comme références est en effet plus légère et souvent plus facile à gérer. Cependant, je recommande d'utiliser cette approche exclusivement lorsque vos fichiers cs sont entièrement autonomes et n'ont pas d'exigences de construction spéciales.
Utilisation de DLL distinctes
rendra les dépendances à d'autres utilitaires ou bibliothèques explicites (donc tant que vous n'avez pas de telles dépendances, cela fonctionnera bien)
vous permettra de définir des configurations de build spécifiques (par exemple, si une classe ne fonctionne qu'en configuration x86, ou a besoin d'au moins .NET 4.0, la configuration de build de l'assembly rend cette exigence explicite).
Donc, surtout si vous avez beaucoup de composants autonomes à classe unique, l'utilisation de la référence aux fichiers est très bien, mais si vous avez des composants référençant d'autres composants ou des exigences de construction spécifiques, je recommanderais d'utiliser des DLL.
Pour atténuer les problèmes de gestion de nombreuses DLL distinctes, vous pouvez soit créer un package d'installation, soit utiliser ILMerge , qui peut intégrer un ensemble d'assemblys dans un seul exécutable. Dans notre environnement, nous traitons le problème différemment, en utilisant un script de déploiement pour chaque application. Ce script garantit que toutes les DLL nécessaires sont toujours livrées en production lorsqu'une nouvelle version d'application est publiée.
Les DLL sont pratiques lorsqu'une application est volumineuse et que certaines parties nécessitent des mises à jour, mais pas l'intégralité de l'application. Donc, si vous écrivez MS Word, il est pratique d'avoir le code de vérification orthographique dans un DLL qui peut être mis à jour sans avoir à mettre à jour l'intégralité de MS Word. Si ce que vous êtes l'écriture est une petite application utilitaire (ou une série d'applications autonomes qui utilisent toutes le même code), cela ne fait pas beaucoup de différence si le code est intégré dans la ou les applications.
Vous l'avez assez bien résumé dans votre question, je n'ai que quelques points à ajouter.
Mono Options est un excellent exemple de package NuGet qui utilise très bien la première approche.
Alternativement, si vous décidez d'utiliser des DLL, vous pouvez utiliser des outils comme Costura pour incorporer cette référence dans votre exécutable en tant que ressource intégrée. Pour l'utiliser, ajoutez simplement le Costura.Fody paquet:
Install-Package Costura.Fody
Qu'une DLL soit plus avantageuse ou non dépend de plusieurs facteurs:
- La taille du code (une fois compilé).
- Combien d'exes l'utilisent.
- La fréquence à laquelle vous avez l'intention de mettre à jour le code.
- Que les ex soient ou non destinés à être maintenus ensemble ou à exister complètement séparément.
Le but d'une bibliothèque partagée est de prendre du code commun à plusieurs exécutables et de le centraliser afin que tous les exécutables partagent une copie. Ceci est destiné à économiser de l'espace et à faciliter la mise à jour du code.
Si la quantité de code dans votre classe d'assistance est très petite, il ne vaut peut-être pas la peine de la déplacer vers une DLL car la surcharge du code dans une DLL peut contrecarrer l'avantage d'économie d'espace de sa centralisation.
De plus, si vous ne créez que quelques exécutables, la taille du code dans chaque exécutable peut être suffisamment petite pour ne pas être un problème. Cependant, plus vous avez d'exécutables utilisant le même code, plus il serait avantageux de déplacer le code dans une DLL.
À titre d'exemple simplifié, supposons que votre classe d'assistance compile sur 128 octets dans un fichier exe, mais lorsqu'elle est déplacée vers une DLL, la DLL est de 512 octets. Si vous n'avez que 3 exécutables, vous économiseriez de l'espace en incluant le code dans les exécutables. Cependant, si vous aviez 5 exécutables, vous seriez alors au point où vous feriez mieux d'avoir une DLL car l'espace combiné occupé par 5 copies du code (5 * 128 = 640 octets) est plus que l'espace occupé en ayant le code dans une DLL (512 octets).
Supposons maintenant, par exemple, que vous trouviez un bogue dans votre code d'assistance. Si vous avez compilé tous vos exécutables avec le code intégré, vous devez recompiler chaque exécutable unique puis redistribuer les versions recompilées. Si vous avez compilé le code en une dll, vous n'auriez qu'à recompiler et redistribuer la seule dll, et le bogue serait automatiquement corrigé pour tous les exécutables l'utilisant.
Enfin, pour qu'un programme trouve une DLL, il doit savoir où chercher la DLL. Si vous conservez tous vos exécutables ensemble, vous pouvez simplement mettre la DLL dans le même répertoire et ils la trouveront tous immédiatement. Si vous les gardez intentionnellement séparés, il devient plus difficile de les coordonner pour utiliser la même DLL.
Votre troisième option est la plus appropriée (ajoutez-la en tant que projet de "bibliothèque de classes" distinct à la solution). Cela combine les avantages de toutes les approches:
- Votre "projet d'aide" est toujours à jour sur tous les différents projets.
- Vous pouvez référencer le code du projet lorsque vous souhaitez voir rapidement les modifications.
- Vous pouvez le créer à chaque fois pour la version .NET correcte.
- Vous pouvez incorporer un DLL dans un exe de toute façon, alors ne vous inquiétez pas, vous pouvez simplement l'avoir dans votre build.
Nous le faisons tout le temps et je ne peux rien faire d'autre que de recommander cette approche.
Une autre quatrième alternative que vous n'avez pas mentionnée est de le placer sur un référentiel privé NuGet qui vous permettrait de le versionner correctement et de le référencer sans le projet supplémentaire dans chaque solution.
En tant que développeur, j'aime toujours inclure la référence de la solution de l'utilitaire à mon application car elle me permet de déboguer le code (et de repérer les éventuels bugs dans l'utilitaire aussi!), Plus toutes les modifications apportées à l'utilitaire sont automatiquement incluses dans l'application.
Donc, en fait, la décision dépend de la maturité de l'utilitaire ! Si vous n'êtes pas sûr des bogues de l'utilitaire, vous devez toujours inclure le fichier .cs de cet utilitaire pour trouver les bogues. Mais si vous êtes sûr que l'utilitaire est suffisamment mature et qu'il ne renverra aucun résultat avec des bogues et là n’a aucune possibilité d’amélioration dans l’utilitaire, vous pouvez continuer et inclure le fichier DLL.