Lorsque la version de la dll de ne pas travailler, mais debug dll ne
Après le déploiement de notre vaste système distribué pour l'un de nos clients, nous faisons l'expérience d'une erreur inattendue. Au cours de l'enquête, nous remplaçons l'assemblée l'origine de l'erreur avec un où nous avons ajouté un code de diagnostic. La dll que nous utilisons est construit en mode de débogage. Et soudain, tout cela fonctionne!
Remplacement de la dll de débogage avec la version (avec le code de diagnostic) fait planter à nouveau.
Il n'y a pas précompilateur directives, à condition de débogage attributs etc. dans notre code. Le problème a été trouvé dans deux différents sites d'installation, alors que cela fonctionne très bien dans plusieurs autres.
(Le projet est un mélange de C# et VB.NET le troublesom assemblée est VB.NET.., si cela fait une différence)
La question est donc: Que faites-vous dans des situations de ce genre? Et ce qui peut être la cause - en général? Tous les conseils sur le débogage de cette question est la bienvenue.
Je n'ai pas été en mesure de le clouer encore, mais c'est une exception référence nulle (donc qui n'aide pas vraiment!?).
Pourrait, avec la pile des appels. L'examen de la pile des appels est l'une des premières choses que vous devriez faire.
OriginalL'auteur Torbjørn | 2008-12-15
Vous devez vous connecter pour publier un commentaire.
Pour cause... eh bien, un indice du symptôme pourrait l'aider. Une possibilité est que vous avez le code d'une méthode comme
Debug.WriteLine
qui a des effets secondaires (c'est à dire le fait fonctionner). Les appels de méthodes marqué avec[Conditional(...)]
ne sont pas compilés, sauf si vous avez le droit symboles définis -, de sorte que rien marqué[Conditional("DEBUG")]
sera ignoré.Il pourrait également être un bug du compilateur, mais qui est un peu rare (mais pas impossible).
Quel est le symptôme? Comment est-il casser?
Comme un exemple de ce qui précède:
Compilé en mode DEBUG, il imprime "je travaille"; compilé en mode RELEASE, il imprime "je suis cassé". Est-ce à son semblable? Vérifiez que vous n'êtes pas à l'appel de toutes les méthodes de débogage directement avec des choses qui ont des effets de bord. Dans la plupart des cas, vous pouvez résoudre par indirection:
Maintenant, il est appelé dans les deux modes.
OriginalL'auteur Marc Gravell
Vous pouvez essayer de l'éteindre Optimiser le Code dans les Paramètres de construction. Quelle est l'erreur que vous obtenez.
Une autre chose que vous pouvez faire est de compiler en mode release, mais de permettre à l' #Debug conditionnelle. Cela permettra de traiter le cas si votre utilisation des Diagnostics.Débogage et le code n'des effets de votre application.
OriginalL'auteur JoshBerke
Avez-vous essayé d'inclure les fichiers de débogage? (pdb)
Si vous co aller les paramètres de votre projet, puis de le compiler 'onglet" sélectionner votre version validée dans le menu déroulant vers le haut, puis choisissez options avancées options de compilation, vers le bas, assurez-vous de le mettre à créer des informations de débogage, puis redéployer, vous devriez maintenant obtenir des informations plus détaillées sur la raison de l'accident.
OriginalL'auteur Brian Schmitt
J'ai vu le calendrier qui cause des problèmes entre Debug et Release construire. Généralement Debug s'exécute plus lentement que la Libération de construire. Vous pouvez vérifier le temps de la section critique de votre code.
OriginalL'auteur faulty
OriginalL'auteur Ed Guiness
Il pourrait être une sorte de course à condition que vous avez, si vous ne travaillez pas en single-threaded code. Par exemple, si une partie de votre programme doit effectuer certaines actions avant les autres pièces peuvent y accéder, il peut échouer en mode release, tout simplement parce que le code est accessible trop tôt. Nous avons déjà eu un problème similaire avec un peu de code pour les téléphones mobiles qui fonctionnait bien dans l'émulateur, mais sur le téléphone qui a été plus lente, la situation n'était pas du tout la même chose.
OriginalL'auteur Morten Christiansen
Eu le même problème avec un C# DLL contenant un WCF client fourni pour plusieurs applications de client.
A trouvé qu'il y avait une méthode en C# de la bibliothèque du client accédant à la StackTrace à des fins de journalisation, qui se trouve être différent lorsqu'il est compilé en debug.
GetFrame(2)
n'a pas existé dans le communiqué. Plus d'informations à ce sujet peuvent être trouvées ici: StackTrace les méthodes de la classe ne fonctionne pas en mode releaseDrôle, c'est un VB.NET le client a été affecté dans une autre C#.NET un client, il a fonctionné correctement.
Espère que cela aide.
OriginalL'auteur Thiago Carvalho
J'ai eu un problème à un moment avec les finaliseurs allant plus tôt que prévu, parce que je n'arrivais pas à bien comprendre l'interaction entre les finaliseurs, le garbage collector, et quand un objet est considéré comme étant à collectionner (indice: ce n'est pas à l'accolade fermante du bloc). Si votre code utilise les finaliseurs, vous pouvez regarder dans GC.KeepAlive(). Dans le bloc suivant:
f
devient admissible à la finalisation de l'avantSomeFunction()
court même! Si le finaliseur fait quelque chose comme jeter quoi queSomeProp
mains, vous pourriez avoir des ennuis. Ajout d'un appel àGC.KeepAlive(f)
après l'appel àSomeFunction
assure quef
n'est pas admissible pour la finalisation jusqu'à ce que après l'appel àKeepAlive()
.Edit: Après tout ça, j'ai oublié de signaler que ce problème est beaucoup plus prononcée lors de l'exécution en mode Release. Je ne sais pas si la version Debug met implicite Keepalive pour les locaux à la fin de la fonction pour le débogueur, ou si la collecte des ordures est tout simplement moins agressif, ou quoi, mais en mode Release exacerbé ce problème grandement dans mon cas.
OriginalL'auteur twon33
Assurez-vous que l'Application est en construction sous la Plate-forme correcte de la Cible. Cela peut être un problème surtout quand il s'agit de fournir ou de consommer de l'Dll. Regardez sous "Projet->Propriétés" et sélectionnez "Build" de l'onglet. La Plate-forme cible option vous permettra de sélectionner entre une unité centrale (par défaut), x86 ou x64.
OriginalL'auteur Israel Rivera
Tout d'abord désolé pour mon anglais. Je sais que ce post est vieux mais je viens de le même problème, et je me rends compte qu'en mode debug, le build est fait pour OS 32 bits, et le mode de libération est pour 64 bits par défaut. Ce faire de la dll est fait pour la version 32 bits ne fonctionne pas dans le communiqué. Si vous allez dans les propriétés du Projet -> build vous pouvez choisir l'architecture que vous souhaitez. Cela fonctionne pour moi.
Au revoir.
OriginalL'auteur Leandro
Vous le savez sans doute, mais,
les variables sont parfois initialisé différemment en debug et release.
E. g.
Je pense que les variables sont auto-init avais en VC6 debug, cela peut cacher des problèmes si vous n'avez pas initialiser quelque chose. Je pense aussi debug tableaux peuvent utiliser sentry octets dans une tentative pour indiquer les dépassements. Cela peut aussi conduire à des comportements différents.
OriginalL'auteur Cokes
Avez-vous résolu votre problème?
Je vais avoir le même problème que vous.
Si j'ai compiler la dll dans le debug, tout fonctionne très bien.
Si je compille dans libération-je obtenir une référence nulle exception.
Mais si je comprend certaines lignes comme ci-dessus dans certaines méthodes d'appel, l'exception est allé de même en mode release:
Système.Diagnostics.Le journal des événements.WriteEntry("blablabla", "blablabla")
Espère que vous aide.
OriginalL'auteur Carlos Bomtempo
J'ai eu un problème similaire. Ma situation comme ceci:
J'ai défini une réflexion fonctions dans une bibliothèque de classe A. Puis j'ai défini une bibliothèque de contrôles utilisateur WPF B, qui utilise les fonctions de la bibliothèque A. Ensuite, j'ai codé une application qui utilise le contrôle de l'utilisateur à partir de la bibliothèque de B et de fonctions dans la bibliothèque de A. Lorsque j'ai utilisé la version de débogage de la bibliothèque de B, il fonctionne très bien. Mais quand j'ai utilisé la version de bibliothèque B, la réflexion fonctions n'ont pas de travail. J'ai également défini d'autres fonctions dans la bibliothèque de A. Il semble que seule la réflexion fonctions sont à l'origine de la difficulté. Je ne peux pas comprendre la raison. Finalement, j'ai renoncé et a déménagé à la réflexion des fonctions de la bibliothèque à la bibliothèque B. Et cela a fonctionné.
OriginalL'auteur
Dans mon cas, c'était que ma DLL projet des consommateurs (VS) avait x64 configuration, mais la solution était dans la CPU.
Pour une raison que lors de l'exécution de l'application, cela n'a pas de crochet avec mon x64 DLL.
J'ai configuré l'application d'un x64 explicitement plate-forme et tout a fonctionné correctement.
OriginalL'auteur Víctor Carreño
Ce n'est probablement pas pertinente pour la question d'origine, mais pour toute personne qui exécute une application qui utilise
il est possible que l'appeler pour obtenir insérée dans une méthode dans une autre assemblée au moment de l'exécution, et par conséquent, pour obtenir un résultat inattendue (comme mentionné dans le La documentation MSDN).
Pour éviter cela, vous pouvez soit appliquer un
MethodImplAttribute
à votre méthode:ou vous pouvez passer à l'utilisation de
Assembly.GetExecutingAssembly()
à la place.OriginalL'auteur Ant