Nunit.exe ne peut pas fonctionner sur Vista 64bits si la construction x86

Question

Je suis sur Vista 64 bits et j'ai un projet construit avec une configuration x86. Tout fonctionne bien. Nous sommes maintenant sur le point de créer un test. Nous avons NUnit 2.4.8 mais nous avons beaucoup de problèmes.

Les tests se chargent via Nunit.exe (interface graphique) lorsque nous sélectionnons directement le fichier .dll, mais lors de l’exécution, nous avons une exception système.badimageformatexception.

J'ai lu sur Google quelques astuces concernant le fichier nunit.exe.config, mais aucun ne fonctionne. (passage à UTF8 ... décommentez la version .net pour le démarrage).

Une idée?

Mettre à jour

J'ai nettoyé la solution et effacé tout le dossier BIN. Maintenant, quand je compile, je vois clairement que je n'ai que le répertoire / x86 / dans le répertoire bin et pas l'ancien / debug / qui était en x64.

Quand j'y vais avec Nunit, j'ai une exception (dans le chargement): System.IO.FileNotFoundException ...

Trace de la pile du serveur:    at System.Reflection.Assembly._nLoad (AssemblyName nomFichier, String codeBase, Evidence assemblySecurity, emplacement de l'assemblageHint, StackCrawlMark & ??amp; stackMark, Boolean throwOnFileNotFound, Boolean pourIntrospection)    at System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & ??amp; stackMark, Boolean forIntrospection)    at System.Reflection.Assembly.InternalLoad (String assemblyString, Evidence assemblySecurity, StackCrawlMark & ??amp; stackMark, Boolean forIntrospection)    à System.Reflection.Assembly.Load (String assemblyString)    à NUnit.Core.Builders.TestAssemblyBuilder.Load (chemin de la chaîne)    à NUnit.Core.Builders.TestAssemblyBuilder.Build (String assemblyName, Boolean autoSuites)    sur NUnit.Core.Builders.TestAssemblyBuilder.Build (String assemblyName, String testName, Boolean autoSuites)    sur NUnit.Core.TestSuiteBuilder.BuildSingleAssembly (package TestPackage)    sur NUnit.Core.TestSuiteBuilder.Build (package TestPackage)    sur NUnit.Core.SimpleTestRunner.Load (package TestPackage)    sur NUnit.Core.ProxyTestRunner.Load (package TestPackage)    sur NUnit.Core.ProxyTestRunner.Load (package TestPackage)    sur NUnit.Core.RemoteTestRunner.Load (package TestPackage)    sur System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage (IntPtr md, Object [] args, serveur Object, Int32 methodPtr, Boolean fExecuteInContext, Object [] & amp; outArgs)    à l'adresse System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (msgraphe IMessage, méthode Int32 Intra, Boolean fExecuteInContext)

Exception renversée à [0]:    sur System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (demande de message, message de réponse, message de messagerie)    à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & msgData, type Int32)    sur NUnit.Core.TestRunner.Load (package TestPackage)    sur NUnit.Util.TestDomain.Load (package TestPackage)    at NUnit.Util.TestLoader.LoadTest (String testName)

Mise à jour 2

Je compile avec TOUT CPU que j'ai modifié pour être x86 au lieu de x64. La raison en est le débogage . Cela a déjà été discuté dans le lien précédent. Je dois confirmer que NUnit fonctionne dans 64bits mod et Corflags.exe

Answer 1

Ok, j'ai trouvé la solution dans ce site Web . Vous devez utiliser \ NUnit-2.4.8 \ bin \ nunit-x86.exe à la place de \ NUnit-2.4.8 \ bin \ nunit.exe ... ne savait pas que le \ bin \ avait 2 nunit !! !

Merci à tous

Answer 2

L’hôte NUnit s’exécute probablement en tant que processus 64 bits (vous pouvez le confirmer en consultant le gestionnaire de tâches). Si votre assemblage correspond uniquement à x86, il ne pourra pas être exécuté dans ce processus.

Vous pouvez essayer d’exécuter corflags sur le NUnit exécutable pour le forcer à exécuter x86, à l'aide de l'indicateur / 32bit +

Answer 3

Cela peut également se produire lors de la mise à niveau de TeamCity 3.1 à 4.0 sur un serveur de génération x64 avec MSBuild Run Platform défini sur x86. Le coureur de TeamCity semble utiliser la plate-forme par défaut différemment de la version 4.0 à la version 3.1, ne respectant pas le fait que la construction utilise x86.

Dans mon cas, le premier correctif qui a fonctionné a été l'ajout d'un remplacement de plate-forme à l'appel NUnit dans mon script MSBuild:

<NUnit Assemblies="Test/bin/$(Platform)/$(Configuration)/Test.dll" Platform="x86" /> 

(c.-à-d., le moyen de passage par le test dans TeamCity de forcer le format 32 bits comme dans les autres suggestions)

(Cela inclut lorsque la cible de la plate-forme de l'assemblage de test est Tous les processeurs (même si cela arrive, je les ai définis explicitement sur x86 car certains tests chargent dynamiquement les DLL limitées à x86)).

Answer 4

Pourquoi utilisez-vous la configuration x86 et non pas un processeur?

J'imagine que lorsque vous chargez NUnit, il a été construit avec l'option Tout processeur, donc JIT au code x64. Lorsque cela tente de charger vos tests spécialement compilés pour une exécution en tant que x86, il lève l'exception.

J'essaierais de modifier tous les paramètres de configuration pour tous les processeurs et de voir si cela résout votre problème.

Answer 5

Si vous utilisez TeamCity, vous pouvez ajouter la propriété teamcity.dotnet.nant.nunit2.platform avec la valeur x86 aux paramètres de construction dans les paramètres de configuration de votre projet TeamCity ( dans la section Propriétés et variables d’environnement).

Answer 6

Avait le même problème avec TeamCity 8.1. Ce qui a résolu le problème, c'était de changer l'étape de génération de NUnit .NET Runtime / de la plate-forme: à x86

.

J'ai également dû modifier l'exécution des tests de: chemin de TestProject \ bin \ Release à TestProject \ bin \ x86 \ Release p>