Bonjour, 

Je travaille actuellement sur un projet en C# avec Xamarin et je manipule et créé des dll.

J'ai mon projet de base (appelons-le API_Xamarin) qui utilise des dll. Jusque là tout va bien, j'arrive à utiliser les différentes méthodes et variables (prenons en exemple une variable du type "Util").

Mon projet a pour but d'être une API et d'autres utiliseront donc la dll de ce projet. Seulement voilà, j'ai fait un projet de test (API_Test) dans lequel j'inclus ma dll API_Xamarin.dll (prise dans le bin/Debug) et dans ce projet de test il m'est impossible de déclarer une variable du type "Util"...

Mes questions sont donc les suivantes :

• est-ce que ma dll API_Xamarin.dll inclut les dll dont je me sers dans le projet API_Xamarin ? (et donc j'ai mal fait qqch)
• ou est-ce que je dois inclure dans mon projet API_Test les dll précédemment incluses dans API_Xamarin ?

En vous remerciant par avance pour le temps que vous voudrez bien accorder à ma question !

Salut !

Taux de certitude 10% vu que je ne l'ai jamais fait, mais il ne faut pas inclure la DLL dans le projet via NuGet ?

[EDIT] En fait je suis débile, je viens de comprendre... Et je crois que la réponse est non. Pour moi chaque DLL représente une assembly à part. Enfin encore une fois je l'ai jamais pratiqué mais c'est ce que j'ai compris du cours...

-
Edité par galactose 29 mai 2019 à 20:13:09

Static linking vs Dynamic linking

Bonjour, 

Merci pour vos réponses même si j'avoue que malheureusement je ne suis pas vraiment plus avancé.. 

J'aimerai pouvoir fournir à la fin une seule dll mais je crois que je vais devoir fournir également les autres dll que j'utilise puisque quand je build ça me met systématiquement toutes les dll dans le Debug (ou dans le Release, j'ai essayé les deux).

Est-ce un fonctionnement propre à .NET de ne pas "fusionner" les dll ? En Java J'ai l'unique dll de mon projet à fournir et tout fonctionne..

ThibaudBurki a écrit:

Bonjour, 

Merci pour vos réponses même si j'avoue que malheureusement je ne suis pas vraiment plus avancé.. 

J'aimerai pouvoir fournir à la fin une seule dll mais je crois que je vais devoir fournir également les autres dll que j'utilise puisque quand je build ça me met systématiquement toutes les dll dans le Debug (ou dans le Release, j'ai essayé les deux).

La réponse est pourtant écrite dans le texte...

Dans ton cas, tu es effectivement amené à joindre toute les dll au dossier de build. Tu peux contrôler le dossier d'output de chacun des projets de la solution dans les propriétés du-dit projet (et ce, en fonction de la configuration). 

ThibaudBurki a écrit:

Est-ce un fonctionnement propre à .NET de ne pas "fusionner" les dll ?

Non, ce n'est pas un comportement propre à .NET.

Les DLL (Dynamic Link Library) sont faites pour être liées dynamiquement et demandent à être présentes sur le système lors de l'exécution d'un programme qui les nécessitent.

D'accord d'accord, je commence à y voir un peu plus clair.

Par contre on veut de moi que je fournisse une seule dll à la fin... N'y a-t-il pas une solution détournée pour y parvenir ? 

Il y a un amalgame total entre Dll en général et assembly .NET stocké dans une Dll.

Il faut savoir de quoi vous parlez.

En JAVA, l'équivalent des assemblies .NET, c'est des JAR, pas des Dll.

De quelle Dll JAVA parlez-vous ???

Il est assez facile de fusionner des Dll mais cela n'a généralement aucun intérêt et bien des inconvénients.

Mais pour vous donner une solution effective, il faut savoir précisément de quoi vous perlez et les contraintes exactes ?

Avec les mécanismes de déploiements modernes, la fusion des livrables n'a aucun intérêt.

Bonjour, 

Je me suis trompé, il s'agit bien d'un fichier JAR Java et non pas d'une DLL. J'avais la tête en plein dans les DLL donc j'ai placé ce mot un peu partout sans faire attention ! 

Je fais un petit récap de la situation : 

Projet Java : 2 bibliothèques incluses + tout un paquetage fait main. En sortie : un fichier (.jar) 

Projet C# (qui est une conversion du projet Java) : 2 bibliothèques incluses + tout un paquetage fait main. En sortie : les deux bibliothèques + le paquetage (.dll)

Mon objectif : 

Arriver à faire avec le projet C# la même chose qu'en Java, à savoir fournir un seul fichier et non pas 3 comme c'est actuellement.

Donc dans mon cas il pourrait être intéressant d'arriver à fusionner les DLL. J'aimerais au moins essayer et voir ce que ça donne.

Vous n'êtes pas très rigoureux.

Les bibliothèques en JAVA, ça n'existe pas. L'équivalent de bibliothèques du C, ces les JAR.

Idem pour C#, les bibliothèques, ça n'existe pas.

Donc, je vois pas trop ce que vous voulez faire, en fait, à part faire un déploiement à "comme il y a 30 ans, tout pourri, qui casse potentiellement tous".

En JAVA, vous êtes quasiment toujours obliger de fourrer votre produit dans un .jar pour que la VM JAVA fasse son travail.

En C#/.NET, vous êtes bien plus libre de faire ce que vous voulez.

Si c'est pour faire une simple tâche à la con, pourquoi ne pas simplement générer un exécutable ?

bacelar a écrit:

Vous n'êtes pas très rigoureux.

Les bibliothèques en JAVA, ça n'existe pas. L'équivalent de bibliothèques du C, ces les JAR.

Idem pour C#, les bibliothèques, ça n'existe pas.

Pour information, la traduction de "library" n'est pas "librairie" mais bien "bibliothèque" et de ce fait, elles existent. Voyez plutôt :

Libraries are fundamental to Java. They allow, in part, the JVM's classloader to locate classfiles. (I will explore classloaders in a future article.) For that reason, Java's libraries are commonly known as class libraries. However, Java refers to class libraries as packages. (https://www.javaworld.com/article/2074542/core-java-packages-organize-classes-and-interfaces.html)

Et cet article sera aussi à lire je pense : https://www.c-sharpcorner.com/UploadFile/1e050f/creating-and-using-dll-class-library-in-C-Sharp/

Enfin bref, les bibliothèques existent dans ces deux langages, c'est une aberration de dire le contraire. Simplement ça ne porte pas forcément directement ce nom ou bien c'est ajouté à une archive par après.... 

Je ne m'attarderai pas sur cette magnifique phrase... 

bacelar a écrit:

Il y a un amalgame total entre Dll en général et assembly .NET stocké dans une Dll.

 ... mais je crois que Microsoft ne dit pas tout à fait la même chose : Les assemblys prennent la forme d’un fichier exécutable (.exe) ou d’un fichier de bibliothèque de liens dynamiques (.dll) et sont les blocs de construction des applications .NET. (https://docs.microsoft.com/fr-fr/dotnet/standard/assembly/)

Enfin bref, pas besoin de cracher comme ça sur le travail des autres, si je demande à faire certaines choses c'est que j'en ai besoin... 

Il me semble que les NuGet peuvent être ma solution, je vais fouiller de ce côté.

Merci à ceux qui ont apporté des réponses constructives !

ThibaudBurki a écrit:

Les assemblys prennent la forme d’un fichier exécutable (.exe) ou d’un fichier de bibliothèque de liens dynamiques (.dll) et sont les blocs de construction des applications .NET. (https://docs.microsoft.com/fr-fr/dotnet/standard/assembly/)

Respire, prend le temps de te calmer, et relis.

Vous n'êtes pas rigoureux, cela ne veut pas dire que vous êtes le seul, loin de là.

On peut faire des raccourcis dans des discutions à l'oral, dans des articles de vulgarisation ou quand on s'adresse à des pairs ayant un niveau de maitrise connu et que cela n'entraine pas de confusion.

L'article java utilise une police en italique très vraisemblablement pour "admettre" que c'est vraiment un gros abus de langage.

Lisez attentivement l'article et vous verrez qu'il ne mention "library" que dans l'abstract de son article, qui ne porte que sur le bon usage des "packages". Il fait référence à des abus de langage courant en JAVA, qui ne pose pas de problème quand on sait de quoi l'on parle (ce que vous ne semblez pas vous rendre compte).

Le "concept" de librairie existe, comme dans tout langage un peu évolué, ayant moins de 40 ans. Mais ce n'est qu'un concept, rien de concret, contrairement au C ou au C++ ou tout autre langage capable de faire une transcription C comme Python.

Donc, au lieu de faire le "kéké", aidez-nous à vous aider, en répondant précisément à nos questions.

>Projet Java : 2 bibliothèques incluses + tout un paquetage fait main. En sortie : un fichier (.jar)

Parle-t-on donc d'un simple fichier .jar contenant des classes dispatchées dans 2 packages JAVA distincts ?

Pour ce qui est de l'article C#, ce n'est que la reprise de la dénomination d'un type de projet permettant de créer un assembly sous forme d'une Dll regroupant des classes. Le terme de "bibliothèque" n'est là que pour guider l'utilisateur dans l'usage le plus courant d'un assembly mono-fichier.

>Enfin bref, les bibliothèques existent dans ces deux langages

Conceptuellement oui, mais concrètement, NON. Vous axez votre expression de votre besoin sur ce truc qui concrètement ne veut rien dire de précis.

Donnez-nous votre besoin en précisant ce que vous comprenez par le terme "bibliothèque" en Java.

Merci.

Et essayez de comprendre les articles que vous donnez en référence, sinon, vous ferrez toujours les mêmes amalgames.

NuGet permet, principalement, d'intégrer des ressources, aussi bien des sources que des assemblies, des outils de compilations, de la configuration de projet, etc..., dans un projet VS. On est très très loin de votre problématique (ou plutôt ce que vous nous laissez comprendre de celle-ci, malheureusement).

La construction d'un exe ou d'un MSI me semble bien plus simple si c'est juste pour avoir une installation simple d'une application avec des Dll "privée" (ce qu'il faut toujours privilégier).

>Merci à ceux qui ont apporté des réponses constructives !

Si vous n'êtes pas assez précis et que vous nous aidez pas à comprendre votre problématique, ça n'avancera pas.