J'ai remarqué que je peux ajouter une référence non seulement à une DLL, mais également à un EXE dans Visual Studio et accédez à toutes les classes de l'EXE que c'était une DLL.
Y a-t-il une raison pour créer une DLL ou puis-je aussi faire référence à l'EXE?
Je demande parce que j'écris souvent des programmes .NET que je rencontre à la fois sous Windows et sous Mac OS et ma solution habituelle consiste à créer une DLL avec la fonctionnalité, puis deux gites, une pour chaque cible.
Cependant, il me semble maintenant que si je pouvais simplement écrire une version Windows de mon application, puis ajoutez la version Windows (le fichier EXE) à mon projet MAC et référencez l'exe Windows plutôt qu'à une DLL. Il a également l'avantage supplémentaire que je puisse exécuter la version Windows dans le dossier Mac sans ajouter un autre fichier.
Y a-t-il une bonne raison de ne pas le faire de cette façon?
3 Réponses :
Cela dépend de la quantité d'entretien / de mise à jour que vous finiriez par faire aux applications. J'aime la propreté du modèle d'origine, où l'interface utilisateur est séparée en fonction de la plate-forme, et les DLL contiennent les classes partagées. Je le trouverais moins déroutant pour la maintenance / refactoring.
Peut-être. Mais même dans le cadre de l'interface graphique et de la logique commerciale du projet, des classes et des fichiers séparés sont toujours dans des classes et des fichiers séparés. Et il a l'avantage que la version de la plaine .NET (qui utilise Windows Forms) est un fichier EXE unique sans fichiers de support requis. La version Mac a besoin de beaucoup de fichiers de support mais vient dans un ensemble.app.
Si vous le souhaitez, vous pouvez créer toutes vos assemblées comme exécutables (.exe) et les références. Il n'y a pas de différence pour .NET si un assemblage est compilé comme exécutable (.exe) ou une bibliothèque de classe (.dll).
Le seul diffrence est qu'un exécutable dispose d'un exécutable portable (PE) format et en-tête , afin qu'ils puissent être exécutés sur des systèmes Windows. Il s'agit principalement de cet en-tête utilisé pour lancer le temps d'exécution CLR.
Donc, dans mon cas où il s'agit d'un avantage de faire référence à un fichier EXE plutôt qu'à une DLL (à savoir qu'un programme Windows entièrement fonctionnel se déroule avec la version Mac), il n'y a pas de véritable inconvénient à le faire, sauf les avantages habituels de ne pas avoir divisé l'EXE dans une dll et un exe?
Je vois au moins deux raisons pour lesquelles on devrait encore diviser /
Ce sont des arguments permettant de scinder une application dans des fichiers EXE et DLL distincts, pas nécessairement des raisons de ne pas faire référence à un fichier EXE. J'ai besoin de savoir s'il ya des raisons de ne pas faire référence à un fichier EXE, évidemment, en plus des raisons générales de diviser une application en fichiers d'interface graphique et d'entreprise.
Dans ce cas, votre EXE Windows comprend-il les portions d'interface utilisateur que vous auriez auparavant éventuellement séparées (si c'était une DLL)?
Oui. Cela pourrait être couru séparément et je pense que c'est un avantage.