code source même sur deux machines donnent différents comportement exécutable

Question

Voici le scénario:

projet A Application Windows stockée dans SVN est utilisé pour créer un fichier exécutable. Normalement, un serveur de construction gère le processus de construction et crée des générations à intervalles réguliers qui sont utilisés par les tests. Dans ce cas particulier, on m'a demandé de modifier une construction spécifique et de créer l'exécutable.

Je ne suis pas entièrement sûr si le serveur de construction modifie les fichiers du projet, mais je sais qu'il crée une balise dans le SVN du code source utilisé pour compiler les exécutables. En utilisant cette balise, j'ai vérifié le code sur une deuxième machine, qui est une machine de développement. J'ai ensuite compilé la source sur la machine de développement. Lorsqu'elle est exécutée, l'application qui a été compilée sur la machine de développement ne fonctionne pas exactement comme celle compilée par le serveur de construction. Par exemple, sur les machines de test, une exécution DateTime Parse est détectée par l'application. Cependant, l'exécutable de la machine de construction ne lance aucune exception. Si je cours l'exécutable sur la machine de développement aucune exception n'est levée. Donc, en résumé, les deux machines utilisent théoriquement le même code source et les mêmes projets.
L'exécutable de la machine de développement ne fonctionne que sur la machine de développement. L'exécutable de la machine de construction fonctionne sur toutes les machines, y compris la machine de développement. Les paramètres régionaux ou le fuseau horaire de la machine sont-ils stockés dans le fichier exécutable compilé?

Une idée de ce qui pourrait causer ce comportement ou comment vérifier les exécutables pour trouver les différences possibles et les corriger?

Malheureusement, je ne peux pas prendre une machine de test et y attacher un débogueur. Dès que je peux, je le ferai.

Answer 1

L'application utilise les paramètres régionaux de la machine sur laquelle elle s'exécute, et il semble que c'est votre problème. Vous pouvez forcer un thread à utiliser une culture spécifique en définissant System.Threading.Thread.CurrentThread.CurrentCulture et System.Threading.Thread.CurrentThread.CurrentUICulture sur une valeur spécifique.

Answer 2

Pouvez-vous exécuter le programme sur l'ordinateur de construction sous un débogueur?

Si oui, puis déboguer le problème - il n'y a pas besoin de deviner. Si le débogueur de la machine de développement rencontre l'exception, définissez un point d'arrêt au même endroit sur la machine de construction. Voyez ce qui est différent entre les deux.

Answer 3

Il est possible que les deux machines aient des versions différentes d'une DLL sous-jacente qui ne fait pas partie de votre processus de génération. J'ai vu cela se produire lors de la distribution de services à travers notre ferme de serveurs interne.

Answer 4

J'ai eu un problème similaire une fois (sauf en C++) Quand j'ai comparé les tailles des exécutables compilés, ils étaient loin. Malheureusement, après des jours de recherche, la meilleure solution que j'ai trouvée était de désinstaller VS05 et de le réinstaller.

Answer 5

J'ai vu différentes "Options régionales et linguistiques" sur XP provoquer ce genre de comportement. Est-ce que cela correspond aux deux machines? Démarrer | Paramètres | Panneau de contrôle | Options régionales et linguistiques ...

Answer 6

Pourquoi utilisez-vous un serveur de construction de toute façon, pour le code C#, si je peux demander?

Les temps de construction pour C# lorsque je l'utilisais étaient à peine perceptibles (< 2s). L'application est-elle vraiment si grande?

Answer 7

J'ai quelques questions - les deux machines ont-elles des réglages régionaux identiques et où se trouvent vos journaux d'erreurs? J'espère que ;-) vous avez des exceptions étant traitées et écrites sur le disque, les journaux d'événements .. quelque chose pour aider avec des problèmes comme celui-ci.

D'où vient la date en cours d'analyse? Si c'est dans votre base de données, vous avez peut-être aussi de mauvaises données.

Answer 8

Le système de construction crée probablement une version de version, tandis que la construction manuelle sur le PC de développement fait une version de débogage. La version de débogage contient plus d'erreurs de vérification. Voyez si vous pouvez créer manuellement une version de version et voir s'il y a encore des différences.

Answer 9

Le même code source rarement si tout construit le même programme sur différents ordinateurs. Vous devez toujours supposer que les programmes sont différents, ne vous attendez jamais à ce qu'ils soient identiques. Dans un environnement comme Linux avec un bon gestionnaire de paquets et des mises à jour périodiques et/ou aléatoires, n'espérez pas non plus que le même code source construise le même programme sur le même ordinateur. Plus le langage est élevé, plus il devient mauvais. Construire un programme pour le débogueur est radicalement différent de la construction pour la libération. La version du débogueur, même sans le débogueur, cache les bogues que vous ne trouverez pas jusqu'à la version finale. Vous devez essentiellement déboguer le programme deux fois si vous comptez trop sur un environnement de débogage.