Bonjour à tous, j'utilise une dll pour mon projet (SnmpSharpNet) qui fonctionne très bien en console. Ce projet est un plugin donc pour débug je m'attache au processus du logiciel, seulement voilà, je reçois l'erreur suivante :

+        $exception    {System.IO.FileNotFoundException}    System.Exception {System.IO.FileNotFoundException}

En creusant j'ai trouvé :         _message    "Impossible de charger le fichier ou l'assembly 'SnmpSharpNet, Version=0.9.4.0, Culture=neutral, PublicKeyToken=b2181aa3b9571feb' ou une de ses dépendances. Le fichier spécifié est introuvable."    string

J'ai pourtant bien ajouté la dll en référence dans le projet donc je ne comprend pas. D'ailleur petite question de culture général en passant, lorsque j'ajoute des dll à un projet, sont-elle dans la dll du projet lorsque celui ci est généré ou à chaque fois le programme cherche le chemin de la dll?

Merci de vos réponses par avance, je continue de chercher une solution.

Essaie de mettre la DLL dans le repertoire de ton exe.

meme reponse à ta question de culture.
Les DLL des dépendences sont dans le repertoire de l'exe.
(ILMerge, par exemple, permet de tout rassembler en un seul fichier (dll + exe)) 

Ah merci beaucoup, cela fonctionne parfaitement. Je passe en résolu mais j'aimerais savoir pourquoi certaine dll ont besoin d'être à coté de l'exe alors que d'autre non?

Il ne faut pas confondre Dll et assemblies.

>J'ai pourtant bien ajouté la dll en référence

C'est l'assembly, pas la Dll.

Vous ne faites qu'indiquer que votre assembly, produit final du projet, sera dépendant de l'autre assembly. VS gère cette dépendance soit en faisant une copie local au projet, soit en gardant un lien/chemin vers le fichier contenant l'assembly.

Lors du lancement d'une session de débugging, VS copie ces assemblies à coté du résultat final du projet.

Vous pouvez configurer où l'exécutable va chercher les assemblies en modifiant le fichier de configuration de l'exécutable.

J'ai du faire face au même type de problème que j'ai résolu ainsi

Symptôme : entre deux ouverture de Visual Studio, et malgré aucune modification sur le code, j'ai cette régression qui apparaît (je trouve ça génial ... tu touches à rien et plus rien ne marche, c'est merveilleux)

Résolution : J'ai fait du débugging à la pelleteuse, j'ai téléchargé WinMerge et fait un gros diff entre mon backup de projet original et la version courante qui du coup ne fonctionnait plus avec ce pb d'assembly remonté.

J'ai détecté effectivement tous les diffs liés à mes modifs de code mais je me suis focalisé sur les fichiers "système" de Visual Studio, et bingo ! c'est dans le fichier *.csproj de mon entity BDD (mon projet est un backend qui fournit une API web, décomposée en deux sous-projets, l'API elle-même et l'entity dataaccess qui héberge la base de données derrière, c'est d'ailleurs dans ce second volet que le mal se terrait) :

- une cible "x64" avait été ajoutée par je ne sais quelle magie de l'IHM VS ... je l'ai virée et tout refonctionne correctement.

Je me permets de compléter ici même si c'est un vieux sujet parce que j'ai galéré avant de trouver la réponse moi-même, j'ai bien vu deux trois pistes sur le net mais VS est un tel sac de noeuds ...

Bravo en tout cas d'avoir fait un IDE dans lequel on peut faire des modifs de conf projet en dur sans les enregistrer et qui font qu'on perd le build opérationnel ! Merci Microsoft !

>je trouve ça génial ... tu touches à rien et plus rien ne marche, c'est merveilleux

Parce que c'était tombé en marche. Dites-vous que vous avez de la veine que cela n'arrive pas en production.

>j'ai téléchargé WinMerge

Heu, sinon les outils de gestion de version comme Git, SVN, etc..., c'est un peu fait pour, mais en beaucoup plus pratique. ;-)

Une cible, elle n'apparait pas par l'action du saint-esprit mais plutôt en bidouillant l'IHM avec des moufles.

Tout le monde fait des miss-click.

Souvent, les drivers/connecteurs aux bases de données ne sont que 32bits.

Vous auriez pas oublié de lire au moins 2/3 warning lors de la compilation "complète" de la solution, dans la fenêtre "output" ?

Il y a un site dédié au rapport de bugs chez M$, et c'est pas ici.

https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019

Mais clairement, votre description du problème est extrêmement light, vous devez être plus factuel, avec un scénario qui n'implique pas de miss-click.

Impossible de charger le fichier ou l'assembly 'file:///C:\inetpub\clicksgenie.com\bin\Select.HtmlToPdf.dll' ou l'une de ses dépendances. Il n'y a pas assez d'espace sur le disque. (Exception de HRESULT : 0x80070070)

escription : une exception non gérée s'est produite lors de l'exécution de la requête Web actuelle. Veuillez consulter la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.

Détails de l'exception : System.IO.FileLoadException : Impossible de charger le fichier ou l'assembly "file:///C:\inetpub\clicksgenie.com\bin\Select.HtmlToPdf.dll" ou l'une de ses dépendances. Il n'y a pas assez d'espace sur le disque. (Exception de HRESULT : 0x80070070)

Erreur source :

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Assembly Load Trace : Les informations suivantes peuvent être utiles pour déterminer pourquoi l'assembly 'file:///C:\inetpub\clicksgenie.com\bin\Select.HtmlToPdf.dll' n'a pas pu être chargé.

Et ?

Le message est assez explicite, non ?

"Il n'y a pas assez d'espace sur le disque."

Le changement d'un assembly peut nécessité de l'allocation mémoire pour sa JIT-compilation, qui peut elle-même demander de l'espace disque (pour le swap).