Discussion :

[ouadie99]

Bonjour,

j'ai un projet A par exemple une application windows (contient plusieures fonctions FctA1,FctA2,FctA3, etc ...) cette application se réferencie sur un Projet B qui est une bibliothéque de classes (contient aussi plusieures fonctions FctB1,FctB2,FctB2,FctB3 etc...).Normalement puisque le Projet B est une référence de Projet A , on peut facilement appeler les fcts de Projet B dans le Projet A

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
FctA1()
{
FctB1();
FctB2();
}
FctA2()
{
FctB3();
}

grosso-modo

Mon objectif est ce que c'est possible d'appeler les fonctions de Projet A dans le Projet B ?c'est à dire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
FctB1()
{
FctA1();
FctA2();
}

a condition sans ajouter une référence de projet A dans le Projet B

en conslusion
j'espére que Mon problématique est clair pour vous, si vous avez des idées ou astuces ou trucs ou pistes à suivre n'hésitez pas de m'aider Merci d'avance

[Graffito]

Dans le projet B, on peut créér un dossier "A" (pas indispensable, mais conseillé).

Dans le dossier "A", on peut ajouter les sources de A en temps que liens.

La manip dans la version US est :

• Click-droit sur dossier "a"",
• Add existing item,
• selectionner les sources de A à relier à B
• Choisir "Add as Link" et non "Add" (en cliquant sur la flèche du bouton "Add").

[Pol63]

réponse étrange à mon avis, ca ne duplique pas les sources ?


sinon ce que tu veux faire est possible techniquement mais peu conseillé, il vaut mieux mettre dans une dll les fonctions de A et B que tu veux pouvoir accéder depuis A et B et mettre cette dll en référence des 2 projets


si tu veux quand meme pouvoir appeler du A à partir du B sans ajouter de référence il faut rechercher l'assembly du nom A dans la liste des assemblies chargé en mémoire
ensuite rechercher le type par son nom dans la liste des types pour rechercher dedans un pointeur vers la méhode par son nom là aussi
pas très clair surement mais tout se passe dans system.reflection
et donc le soucis c'est qu'il faut que la dll ait été appelée pour figurer dans la liste des assemblies chargées, et que tes méthodes ne changent pas de nom dans le temps

[chrisdot]

réponse étrange à mon avis, ca ne duplique pas les sources ?

Non, c'est simplement un lien logique vers l'autre source. Par contre ca duplique le binaire, vue que ce sera compilé 2 fois ! Donc vraiment pas top!

sinon ce que tu veux faire est possible techniquement mais peu conseillé, il vaut mieux mettre dans une dll les fonctions de A et B que tu veux pouvoir accéder depuis A et B et mettre cette dll en référence des 2 projets

+1 !!! Mais pourquio c'est pas conseillé???
@ouadie99: Si tu en viens à gérer des référence circulaires, c'est que le code commun n'est pas bien isolé/factorisé... (ce qui est réutilisable doit l'être au bon niveau). A mon avis il suffit de revoir le "paquetage" des quelques méthodes en question, définir qques interfaces et zou... (ça sera à mon avis plus propre)

[ouadie99]

une question pour Pol63
tu me dire un exemple comment utiliser mon cas avec réflexion stp ?

[cinemania]

C'est peut être un lien "logique", mais effectivement ca équivaut à copier le code de A dans B... ce qui ne semble pas être son but.

La problématique des références circulaires peut être vaincue de diverses méthodes.

La Reflexion est en effet une d'entre elles.

Pour cela on inclue le namespace System.Reflection dans le projet.

Ensuite on travail avec les types (ou méta-types) Assembly, Type, MethodInfo

On recherche et localise l'assembly via le type AppDomain, car c'est le seul type de te retourner les assembly en mémoire, ensuite dans cette liste d'assembly on cherche la bonne.
Puis on explore l'assembly et on obtient le descripteur de type sur le type où sont définis tes méthodes à invoquer.
Du descripteur de type Type on obtient alors le(s) descripteur(s) de méthode(s) voulue(s).
De ces descripteurs de méthodes on invoque alors les méthodes, mais ce pose alors la problématique de savoir si elles sont static ou non...

Si elles sont static (shared en vb) cette méthode fonctionnera sans problème, dans le cas où ces méthodes appartiennent à une instance là tu es face à un problème, sauf si tu peux instancier le type qui possède les méthodes voulue sans problème... (Activator)

Voici un peu de code pour illustrer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
var appD = AppDomain.CurrentDomain;
var lass = appD.GetAssemblies();
 
var ass = (from n in lass where n.FullName=="A" select n).FirstOrDefault();
if (ass != null)
{
  var typ = (from n in ass.GetExportedTypes() where n.Name == "nomType" select n).First();
  // Ici le code diffère selon le cas
}

En effet dans le bloc if le code va changer selon que le type à rechercher est un type static (Shared) ou un type à instancier.

S'il faut l'instancier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
var obj = Activator.CreateInstance(typ);
 
var methods = typ.GetMethods();

ensuite de là quand tu dois appeler une méthode tu récupère la bonne en utilisant la propriété Name de chaque élément pour savoir laquelle est la bonne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
var method = (from n in methods where n.Name == "fctA" select n).First()
method.Invoke(obj, new object() {})

le {} permet de définir les arguments d'appel de la méthode séparés par des virgules.
s'il n'y a pas d'argument il faut remplacer le new object() {} par null

si le type est static ou module en vb, alors tu ne passe pas par obj = Activator.CreateInstance() et tu met null (Nothing) en premier paramètre de Invoke.

[kheironn]

Je serais plutôt pour faire simple : créer un projet de type Library et y mettre le code commun... Ca fait une dll en plus, mais c'est réutilisable dans d'autres projets (à venir).

La dll étant référencée dans tes deux projets A et B pour le cas présent.