Le même code source sur deux machines donne un comportement exécutable différent

Question

Voici le scénario:

Un projet d’application Windows C # stocké dans SVN sert à créer un fichier exécutable. Normalement, un serveur de build gère le processus de construction et crée des builds à intervalles réguliers qui sont utilisés par les tests. Dans ce cas particulier, on m'a demandé de modifier une version spécifique et de créer l'exécutable.

Je ne suis pas tout à fait sûr que le serveur de construction modifie les fichiers du projet, mais je sais qu'il crée une balise en SVN du code source utilisé pour compiler les exécutables. En utilisant cette balise, j'ai extrait le code sur une deuxième machine, une machine de développement. J'ai ensuite compilé le code source sur la machine de développement.

Une fois exécutée, l'application compilée sur la machine de développement ne fonctionne pas exactement comme celle compilée par le serveur de compilation. 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 compilation ne lance aucune exception. Si j'exécute l'exécutable sur la machine de développement, aucune exception n'est levée.

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 compilation 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 l'exécutable compilé? Avez-vous 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 le pourrai, 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 ce soit votre problème. Vous pouvez forcer un fil à 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

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 construction. J'ai vu cela se produire lors de la distribution de services sur notre batterie de serveurs interne.

Answer 3

Pouvez-vous exécuter le programme sur la machine de compilation sous un débogueur?

Si tel est le cas, corrigez le problème - inutile de deviner .

Demandez au débogueur sur la machine de développement de capturer l'exception, définissez un point d'arrêt au même endroit sur la machine de construction. Découvrez les différences entre les deux.

Answer 4

J'ai vu différentes " Options régionales et linguistiques " sur XP provoquer ce genre de comportement. Est-ce qu'ils correspondent sur les deux machines? Commencer | Paramètres | Panneau de contrôle | Options régionales et linguistiques ...

Answer 5

J'ai quelques questions à vous poser: les deux machines ont-elles des paramètres régionaux identiques et où se trouvent vos journaux d'erreurs? J'espère que ;-) vous avez des exceptions en cours de traitement et d'écriture sur disque, des journaux d'événements ... quelque chose pour vous aider avec des problèmes comme celui-ci.

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

Answer 6

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

Answer 7

Pourquoi utilisez-vous un serveur de compilation malgré tout, pour le code C #, si je puis me permettre?

Les temps de construction de C # quand je l’utilisais étaient à peine perceptibles (< 2s). Est-ce que l'application est vraiment si grosse?

Answer 8

Le système de construction crée probablement une version finale, tandis que la construction manuelle sur le PC développeur crée 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 et si des différences subsistent.

Answer 9

Le même code source rarement si tous construisent le même programme sur des ordinateurs différents. 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, ne vous attendez pas non plus à ce que le même code source construise le même programme sur le même ordinateur. Plus la langue est élevée, plus la situation empire. La création d'un programme pour le débogueur est radicalement différente de la compilation. La version du débogueur, même sans le débogueur, cache les bugs que vous ne trouverez pas avant la génération de la version. En gros, vous devez déboguer le programme deux fois si vous comptez trop sur un environnement de débogage.