InvalidProgramException/Common Language Runtime a détecté un programme non valide
C’est le problème de programmation le plus étrange que j’ai vu depuis longtemps.
J'utilise Microsoft Visual C# 2010 Express, C# et .NET 2.0 pour développer une application. Cette application fait référence à quelques assemblages dll/(ces dll sont toutes générées sur ma machine).
Ci-dessous une partie du code (ce sont tous des éléments de base):
public class PowerManagement
{
[TestCase]
public void PrepareTest(){
// Configure according to pre-conditions
Preconditions precondition = new Preconditions();
precondition.SetupPreconditions();
...
}
[TestCase]
public void PerformTest(){
TestcaseData testcaseData = new TestcaseData();
// Set Trigger and perform check
switch (testcaseData.triggerNumber){
case (1):
if ((new Trigger1(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
...
case (4):
if ((new Trigger4(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
default:
Report.TestStepFail("Not yet implemented");
break;
}
}
}
Cette application est ensuite générée dans un dll à partir de Visual C# 2010 Express et utilisée ailleurs et tout va bien. Le problème surgit lorsque j'ajoute un autre cas à l'instruction switch ci-dessus (voir ci-dessous)
...
case (4):
if ((new Trigger4(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
case (5):
if ((new Trigger5(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
default:
Report.TestStepFail("Not yet implemented");
break;
Je peux toujours construire sans un seul problème et générer la dll, mais lorsque j'utilise la dll générée, l'erreur suivante apparaît:
A .NET exception (InvalidProgramException) occured in the module PowerManagement
Error message: Common Language Runtime detected an invalid program.
Throwing method: PowerManagement.PerformTest
(le problème se produit même si je copie case(4) et le colle comme un nouveau cas, donc ça n'a rien à voir avec Trigger5- class)
Que se passe-t-il ici? J'ai regardé à travers les autres InvalidProgramException et Common Language Runtime dans Stackoverflow mais aucun ne semblait lié.
Je sais que ce problème est étrange alors faites-le moi savoir et je fournirai plus d'informations. J'utilise une machine Windows 8 64 bits, si cela compte. J'ai déjà vérifié les mises à jour sur les mises à jour VS et .NET. J'ai également régénéré toutes les dll quelques fois et créé la solution à partir de zéro plusieurs fois.
J'ai finalement réussi à résoudre ce problème ..__ J'ai décoché code optimization dans C # Express et cela a résolu les problèmes. Encore la chose la plus étrange, mais puisque nous utilisons d’anciens outils et frameworks, nous ne pouvons vraiment en vouloir à personne.
Je souhaitais simplement ajouter mon expérience à ce sujet ........ Dans mon cas, j’héberge mon API Web C # sur Azure et j’ai rencontré ce message lorsque je tentais de me connecter à mon API . Portail de gestion Azure (portal.Azure.com), accédez à App Services, choisissez mon programme d'API Web et cliquez sur Redémarrer à partir de l'écran Présentation . Après cela, le programme a fonctionné à nouveau normalement. Je n'ai trouvé aucun autre indice dans mes journaux.
J'ai eu ce problème après la mise à niveau vers Visual Studio 2017 v15.8.6 . Le problème a disparu lorsque j'ai supprimé l'attribut assemblyPostProcessorType de la balise de compilation dans web.config.
Essayez d'activer les applications 32 bits dans votre pool d'applications paramètres avancés .
J'ai parfois rencontré cette erreur après un déploiement sur une application Web Azure à l'aide de MSDeploy. L'erreur a toujours disparu après un redéploiement pour la deuxième fois.
Notre construction et notre déploiement sont deux étapes différentes, le redéploiement envoie exactement les mêmes fichiers à chaque fois - cela suggère que le problème n'est pas uniquement lié au compilateur, comme suggéré ailleurs dans les réponses à cette question.
Peut-être un bogue dans MSDeploy ou dans la version de IIS utilisée pour les applications Web dans Azure peut-être ...
J'ai résolu ce problème en procédant comme suit:
- Renommez C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\Outils de performance\Outils de performance\vsinstr.exe en C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\Team\Outils de performance\vsinstr.exe.broken
- Renommez C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\Outils d'équipe\Outils de performance\vsinstr.legacy.exe en C:\Program Files (x86)\Microsoft Visual Studio\2017\Entreprise\Team Tools\Outils de performance\vsinstr.exe
- Reconstruire la solution
Un tel problème pourrait être causé par des bugs dans les outils manipulant l'IL de Assembly après la compilation, par exemple si vous utilisez Fody et ses plugins. Au moins il y a un bug dans Fody MethodDecorator qui provoque un tel effet, voir https://github.com/Fody/MethodDecorator/issues/8
Si vous rencontrez ce problème spécifique à Azure Web Apps - recherchez l'extension installée Microsoft.ApplicationInsights.AzureWebSites - ou son nom convivial l'extension Application Insights pour Azure App Service et supprimez-la via kudu .
Nous avons constaté que cette extension interférait potentiellement avec les poussées msdeploy - un processus snapshotholder_x64.exe était exécuté sous le processus IIS w3wp.exe. Quelqu'un a probablement activé cette extension via le portail Azure.
-uncheck "optimisation du code" (dll référencées incluses) - Mise à niveau vers .net framework 4.6