Discussion :

[Spirk91]

Bonjour,

Je débute en programmation et je rencontre un problème qui me tracasse depuis quelques semaines.
J’ai pour mission d’intégrer un projet sous forme de dll dans un logiciel nommé SmarTeam.
Afin de tester si le code fonctionne, je travaille en debug. Mais une fois que je compile et enregistre la dll afin de l’utiliser dans SmarTeam, le message d’erreur suivant s’affiche :
« Impossible de charger le fichier ou l’assembly ‘Interop.SmReclist, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=null’ ou une de ses dépendances. Le module était censé contenir un manifeste de l’assembly . » Sachant que Interop.SmReclist est une référence utilisée par le projet/dll.
Je ne comprends pas d’où provient le problème sachant que le code fonctionne en debug (en ajoutant un projet supplémentaire permettant de piloter la dll en injectant les informations contenu dans le logiciel (comme une entité sélectionnée par exemple)).

En gros :
- La dll fonctionne en debug (par le biais d’un projet qui lui injecte les informations de la session active du logiciel)
- La dll ne fonctionne pas une fois que celle-ci est intégrée au logiciel (voir message d’erreur ci-dessus)
Pourquoi la dll ne fonctionne pas alors que c’est le cas en debug ? Qu’est-ce que qui diffère entre les 2 cas ?
Si vous avez des solutions à apporter ou bien un regard différent, je suis preneur ! .

Merci à vous !

[mactwist69]

Hello,

Donc tu compiles ton projet dll....
Ensuite j'imagine que tu récupères les DLL générés, ET la dll "Interop.SmReclist" qui doit elle aussi être présente dans Bin/Debug de ton projet Dll

Donc dans ton projet SmarTeam, tu ajoutes en référence la ou les dll de ton projet dll ET la dll Interop.smReclist...

Tu fais bien ceci ?

[Spirk91]

Merci pour ta réponse !

La dll "Interop.SmReclist" est intégré en tant que référence à mon projet et celle ci se retrouve bien dans bin/Debug à chaque compilation.
Interop.SmReclist se retrouve incluse dans ma dll une fois compilé (je pense : j'ai sélectionné ressource incorporé).

[mactwist69]

Mon avis c'est que si "Interop.SmReclist" apparaît dans Bin/Debug, c'est alors qu'il faut le copier également avec les DLL de ton application.

Normalement, dans Bin Debug, tu as tout ce qui est nécessaire et obligatoire.
D'habitude on ne copie que les DLL du projet en lui même, car les dll du Framework se trouve déjà dans les projets cibles.

Mais dans ton cas, la dll particulière a donc besoin d'être présente

[Spirk91]

Interop.SmReclist est directement issu de mon application (SmarTeam). Cette application comporte ses propres ressources qui sont enregistrées dans le registre.
J'ai fais le choix de copier dans le fichier de sorti les dll issus de l'application (ressource incorporée).

[mactwist69]

Alors.... On va refaire un point là... Parce que c'est pas clair.


Tu as deux solutions :

- SmarTeam (Solution 1)
- Solution 2 (Dll)

SmarTeam est une solution qui contient plusieurs projets :
- un projet exécutable (projet de démarrage)
- un projet de type bibliothèque de classe qui donc une dll nommée "Interop.SmReclist"

Dans la Solution 2, tu as importé en référence la fameuse dll "Interop.SmReclist"

Tu compiles ta Solution 2, récupère la dll, et tu l'intègre à SmarTeam (Solution 1)

-> Et quand tu lances SmarTeam en Debug, là, patatraque, il te dis que ta dll de la Solution 2 n'arrive pas a charger "Interop.SmReclist"

Est-ce bien cela ?



PS: Les ressources incorporés, c'est le principe de mettre les fichiers ressources dans l'exe directement en binaire (donc les logos, les images, tous les fichiers annexes).
MAIS pas les fichiers dll qui sont en références. En tout cas je ne crois pas. Donc pour moi, ça c'est hors de propos.

De mon point de vue, pour que SmarTeam fonctionne bien, dans son dossier (Bin/Debug), il devrait y avoir :

l'exe de SmarTeam, les dll éventuelles issus des autres projets de SmarTeam (si ils sont référencés par le projet SmarTeam)
toutes les dll en références issus d'autres projets (donc projet 2)
-> Mais aussi toutes les dll que le projet 2 a lui même en référence (donc toutes les dll de son Bin/Debug à lui)

[Spirk91]

Alors.... On va refaire un point là... Parce que c'est pas clair.


Tu as deux solutions :

- SmarTeam (Solution 1)
- Solution 2 (Dll)

SmarTeam est une solution qui contient plusieurs projets :
- un projet exécutable (projet de démarrage)
- un projet de type bibliothèque de classe qui donc une dll nommée "Interop.SmReclist"

Dans la Solution 2, tu as importé en référence la fameuse dll "Interop.SmReclist"

Tu compiles ta Solution 2, récupère la dll, et tu l'intègre à SmarTeam (Solution 1)

-> Et quand tu lances SmarTeam en Debug, là, patatraque, il te dis que ta dll de la Solution 2 n'arrive pas a charger "Interop.SmReclist"

Est-ce bien cela ?

Pas complètement :

- SmarTeam est un logiciel tel que photoshop par exemple, auquel je souhaite ajouter une fonctionnalité.
- La solution 2 est bien un projet de type bibliothèque de classe qui comporte en référence la dll "Interop.SmReclist". Cette solution 2 permet l'ajout de la fonctionnalité souhaitée.

Dans un premier temps afin de debuger le code de ma solution 2, un projet de démarrage était nécessaire (afin de gagner du temps en n'ayant pas à réintégrer la dll à chaque erreur)
--> le code en mode pas à pas/Debug, fonctionne. Pas de problème de dll.

Ayant un code fonctionnel, j’intègre mon projet de type bibliothèque de classe au logiciel SmarTeam.
--> Et la : la dll de mon projet bibliothèque de classe n'arrive pas à charger "Interop.SmReclist" (voir message d'erreur dans le premier post).

PS: Les ressources incorporés, c'est le principe de mettre les fichiers ressources dans l'exe directement en binaire (donc les logos, les images, tous les fichiers annexes).
MAIS pas les fichiers dll qui sont en références. En tout cas je ne crois pas. Donc pour moi, ça c'est hors de propos.

De mon point de vue, pour que SmarTeam fonctionne bien, dans son dossier (Bin/Debug), il devrait y avoir :

l'exe de SmarTeam, les dll éventuelles issus des autres projets de SmarTeam (si ils sont référencés par le projet SmarTeam)
toutes les dll en références issus d'autres projets (donc projet 2)
-> Mais aussi toutes les dll que le projet 2 a lui même en référence (donc toutes les dll de son Bin/Debug à lui)

Afin de faire marcher ses différentes fonctionnalités, SmarTeam utilise des dll au préalable enregistrées (avec l'outil regasm.exe) dans un fichier bien précis.

PS : Je n'ai ni accès au code du logiciel SmarTeam, ni accès au code de la dll "Interop.SmReclist".

Merci pour votre patience, je fais mon maximum afin d'être le plus clair possible !

[mactwist69]

C'est en effet beaucoup plus clair maintenant !

Je vais surement encore tomber à côté car je ne connais pas bien le système de SmarTeam et de regasm.exe, mais on va avancer logiquement.


Pour intégrer tes dll à SmarTeam, tu utilises donc regasm.exe, qui va assembler dans un fichier (dans le registre) toutes les dll que tu as besoin.
Donc typiquement dedans tu y mets la dll de ta solution 2.

Et c'est là où c'est crucial, comment penses tu que "Interop.SmReclist" est intégré ? (bien que force est de constater qu'il ne l'est pas)

- Tu as mis "Interop.SmReclist" dans ce même fichier en utilisant regasm.exe ?
- Ou Tu penses que "Interop.SmReclist" est intégré à ta dll de ta solution 2 ? (auquel cas, ce ne serait pas le cas)

[Spirk91]

- Tu as mis "Interop.SmReclist" dans ce même fichier en utilisant regasm.exe ?

J'ai ajouté "interop.SmReclist" dans ma solution 2 en le plaçant dans un fichier de l’arborescence projet en tant que ressource incorporée. De plus un module est censé gérer la récupération des dll utilisées :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
'Class virtuelle permettant de récupérer le NameSpace de l'assembly
    Private Class ClassForNameSpace
        Public Shared ReadOnly Property GetNameSpace As String
            Get
                Dim Temp As New ClassForNameSpace
                Return Temp.GetType.Assembly.GetName.Name
            End Get
        End Property
    End Class

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
    'Routine à appeler en début de programme 
    Public Sub EnsureInitialized()
        If Not _Initialized Then
            'ajout d'un évènement déclenché à chaque chargement potentiel de dll
            AddHandler AppDomain.CurrentDomain.AssemblyResolve, AddressOf AssemblyResolve
            _Initialized = True
        End If
    End Sub
 
    'Chargement de la dll demandée 
    Private Function AssemblyResolve(ByVal sender As Object, ByVal e As ResolveEventArgs) As Assembly
        'Récupération du nom complet de la ressource
        Dim resourceFullName As String = ClassForNameSpace.GetNameSpace & "." & New AssemblyName(e.Name).Name & ".dll"
 
        'Récupération de l'assembly
        Dim thisAssembly As Assembly = Assembly.GetExecutingAssembly()
 
        'Chargement de la resource avec libération automatique en fin de procédure (inutile dans le cas d'une dll, mais principe à conserver)
        Using resource As Stream = thisAssembly.GetManifestResourceStream(resourceFullName)
            If resource IsNot Nothing Then Return Assembly.Load(ToBytes(resource))
            Return Nothing
        End Using
    End Function

Ce module est censé permettre de récupérer les dll nécessaires au fonctionnement de ma solution 2 dans mes ressources incorporées (fichier dans l'arborescence projet). Ce qui n'est pas le cas et c'est la que je coince...

[mactwist69]

Ah bah voilà, là on y est.
Ton problème c'est un problème de chargement dynamiquement d'un assembly !

Je n'ai hélas pas tellement de retour d'expérience à t'apporter la dessus !

Mais en utilisant ces mêmes mots clés (avec le mesage d'erreur), je suis certain que tu trouveras plein de sujets comme le tien sur Google/Developpez.com