Question L'application .NET ne peut pas démarrer et recevoir une exception XamlParseException


J'ai écrit une application qui peut installer et travailler sur mon PC de développement (une fenêtre 7).

  • Environnement de développement: Window 7, VS2010 WPF C # avec les deux .NET 4 et .NET 3.5 installée

Sur un autre ordinateur client (XP SP3, 2 et 1), il s’installe sans erreur, mais ne peut pas démarrer. Dans le gestionnaire de tâches, je peux voir que l'application prend brièvement la mémoire avant de se fermer toute seule.

Je m'étais assuré que la cohérence de .NET 3.5 sur l'ensemble de mon PC de développement et de différentes machines client XP était la suivante:

  • Les cibles de l'application .NET 3.5 (ou 3.5 Profil du client)
  • Utilisez le programme d'installation VS2010 pour le déploiement: cibles .NET 3.5 en condition de lancement
  • Aucune erreur sur la compatibilité .NET lors du débogage du projet d'application et du programme d'installation

eventvwr attrapé l'avertissement suivant:

 ¬º˛¿‡–Õ:   ¥ÌŒÛ
 ¬º˛¿¥‘¥:   .NET Runtime
 ¬º˛÷÷¿‡:   Œfi
 ¬º˛ ID:    1026
»’∆⁄:       2011-10-18
 ¬º˛:       15:18:32
”√ªß:       N/A
º∆À„ª˙: WWW-9DB69D5A3AF
√Ë ˆ:
Application: Foo.exe
Framework Version: v4.0.30319
Description: ”…”⁄Œ¥æ≠¥¶¿Ìµƒ“Ï≥££¨Ω¯≥Ã÷’÷π°£
“Ï≥£–≈œ¢: System.Windows.Markup.XamlParseException
∂—’ª:
   ‘⁄ System.Windows.Markup.XamlReader.RewrapException(System.Exception, System.Xaml.IXamlLineInfo, System.Uri)
   ‘⁄ System.Windows.Markup.WpfXamlLoader.Load(System.Xaml.XamlReader, System.Xaml.IXamlObjectWriterFactory, Boolean, System.Object, System.Xaml.XamlObjectWriterSettings, System.Uri)
   ‘⁄ System.Windows.Markup.WpfXamlLoader.LoadBaml(System.Xaml.XamlReader, Boolean, System.Object, System.Xaml.Permissions.XamlAccessLevel, System.Uri)
   ‘⁄ System.Windows.Markup.XamlReader.LoadBaml(System.IO.Stream, System.Windows.Markup.ParserContext, System.Object, Boolean)
   ‘⁄ System.Windows.Application.LoadBamlStreamWithSyncInfo(System.IO.Stream, System.Windows.Markup.ParserContext)
   ‘⁄ System.Windows.Application.LoadComponent(System.Uri, Boolean)
   ‘⁄ System.Windows.Application.DoStartup()
   ‘⁄ System.Windows.Application.<.ctor>b__1(System.Object)
   ‘⁄ System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   ‘⁄ MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   ‘⁄ System.Windows.Threading.DispatcherOperation.InvokeImpl()
   ‘⁄ System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   ‘⁄ System.Threading.ExecutionContext.runTryCode(System.Object)
   ‘⁄ System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
   ‘⁄ System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   ‘⁄ System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   ‘⁄ System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   ‘⁄ System.Windows.Threading.DispatcherOperation.Invoke()
   ‘⁄ System.Windows.Threading.Dispatcher.ProcessQueue()
   ‘⁄ System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   ‘⁄ MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   ‘⁄ MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   ‘⁄ System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   ‘⁄ MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   ‘⁄ System.Windows.Threading.Dispatcher.InvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   ‘⁄ MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
   ‘⁄ MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
   ‘⁄ System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
   ‘⁄ System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame)
   ‘⁄ System.Windows.Threading.Dispatcher.Run()
   ‘⁄ System.Windows.Application.RunDispatcher(System.Object)
   ‘⁄ System.Windows.Application.RunInternal(System.Windows.Window)
   ‘⁄ System.Windows.Application.Run(System.Windows.Window)
   ‘⁄ System.Windows.Application.Run()
   ‘⁄ FooSoftware.App.Main()


”–πÿ∏¸∂‡–≈œ¢£¨«Î≤Œ‘ƒ‘⁄ http://go.microsoft.com/fwlink/events.asp µƒ∞Ô÷˙∫Õ÷ß≥÷÷––ƒ°£

Il y avait cette exception XamlParseException qui empêchait mon application de démarrer sur XP Window Machine. Que se passe-t-il?


33
2017-10-18 03:41


origine


Réponses:


XamlParseException est l'erreur générique qui se produit quand il y a un problème au démarrage de l'application. Je vous suggère de modifier le code de démarrage de votre application pour déterminer ce qui se passe réellement et non seulement l'exception XamlParseException, mais aussi la ou les exceptions internes qui vous aideront à déterminer la source du problème. Voici un exemple:

namespace WpfApplication1
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            // hook on error before app really starts
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            base.OnStartup(e);
        }

        void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            // put your tracing or logging code here (I put a message box as an example)
            MessageBox.Show(e.ExceptionObject.ToString());
        }
    }
}

80
2017-10-22 06:01



Pour commencer, vous avez plus de chance si vous avez construit sur VS2010 .. mais en fait ciblé pour un inférieur version de .Net (3.5, voire 2.0).

Ce serait certainement utile si vous postez un peu de code.

Assurez-vous d'avoir copié tous les fichiers nécessaires à votre application (app.config, etc.).

Ce lien semble similaire:

Le programme .NET 4 écrit / compilé sur Windows 7 ne fonctionnera pas sous XP

Et cela pointe vers ces excellents conseils de dépannage:

Utilisation de Fusion Log Viewer


7
2017-10-18 03:48



Vous pouvez déboguer à distance. Fondamentalement, cela se fait en installant le serveur de débogage distant sur la machine cible, puis en l'attachant depuis votre studio visuel lorsque vous démarrez l'application. Plus d'informations peuvent être trouvées ici: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx et il y a un tutoriel assez âgé ici: http://www.cprogramming.com/tutorial/visual_studio_remote_debugging.html

Veuillez noter que vous devez déployer des symboles de débogage (pdbs) et que le logiciel débogué doit être dans la même version que votre code.


6
2017-10-21 10:21



Bien que vous ayez ciblé .NET 3.5, votre client a été installé et utilisé avec .NET 4. La ficelle

Framework Version: v4.0.30319

ça me dit ça. Pour forcer votre client à utiliser réellement .NET 3.5, vous devez ajouter un App.config à votre application et ajouter:

<configuration>
   <startup>
      <supportedRuntime version="v2.0.50727"/>
   </startup>
</configuration>

Il se peut que vous obteniez une exception car .NET 4 traite votre XAML différemment. Avez-vous essayé de laisser votre application s'exécuter sous .NET 4? Si vous n'avez pas fourni App.config, vous avez malgré tout testé votre application avec .NET Framework 4 bien que vous ayez ciblé .NET Framework 3.5. Si votre client est assez agréable, vous pouvez le laisser créer un fichier de vidage afin de pouvoir le déboguer directement. Télécharger Procdump depuis la suite d'outils SysInternals et l'envoyer avec votre application à votre client. Le laisser exécuter

procdump -ma -e -t -x foo.exe %temp%\dump.dmp

Cela générera un vidage de processus complet pour chaque exception non gérée et un autre lorsque le processus se terminera dans le répertoire% TEMP%. Visual Studio 2010 a obtenu une meilleure prise en charge de l'analyse de vidage, vous devriez donc pouvoir l'analyser dans Visual Studio 2010. Si cela ne vous aide pas, vous pouvez télécharger Windbg (32 bit ici), chargez le dump et tapez

! analyse -v

pour voir quelle était la dernière exception. Cela devrait faire l'affaire. Il peut y avoir des problèmes avec les extensions gérées pour charger le droit débogage dll (sos.dll pour .NET 2,3,3.5 et clr.dll pour .NET 4), mais il existe de nombreux didacticiels en ligne sur la procédure à suivre. En outre, je vous recommande d’ajouter des gestionnaires d’exceptions à votre application pour obtenir un fichier journal intéressant lorsque votre application se termine de manière inattendue.

Si la sortie n'a pas abouti à la bonne pile, vous devez utiliser ! ClrStack et ! Fils pour savoir quels threads ont des exceptions sur leur pile.


6
2017-10-26 19:11



Généralement, je mets des fichiers journaux entre les processus et je connais le déroulement de mon programme.

S'il s'agit d'une application console, mettez Console.WriteLine (une chaîne) et vous pourrez ensuite mettre Console.ReadLine () à la fin pour interrompre l'exécution de votre programme.


5
2017-10-18 03:47



Je suis tombé récemment sur un problème similaire. Le problème que j'avais était sur Windows 7, j'utilisais .ico (fichiers d'icônes). Mais il n'y a pas de support pour ceux-ci sur XP. Dans votre application, si vous utilisez des fichiers d’icône, essayez de les supprimer. Vérifiez si cela résout le problème.


4
2017-10-20 12:51



Commencez par commenter les lignes de code et les classes / méthodes entières de votre code jusqu'à ce que vous obteniez le bon fonctionnement (ou commencez par tout commenter). Puis, commencez lentement à introduire des lignes de code, des appels de méthode, etc. jusqu'à ce qu'il se brise. Cela devrait vous donner une idée de tout code / classe ou référence particulier qui pose problème. C'est certes une méthode fastidieuse, mais en même temps, assez mécanique et en une heure environ, vous devriez avoir une assez bonne idée du coupable.


3
2017-10-18 05:18



J'ai entendu dire que certains codes commentés affectés à l'exécution du fichier de sortie avaient un comportement similaire à celui de votre application (spécialement dans VS 2010, pas une autre version antérieure). mais de l'autre côté, l'année dernière, je travaillais sur un programme dans lequel j'utilisais la suite Dev Component. comme vous le savez sa fissure fonctionne juste dans .Net Framework 3.5 et ma plate-forme de programme était .Net Framework 4. Il se passait la même chose pour votre application, elle est arrivée de mon application. J'ai dû rétrograder ma plate-forme à 3,5 et son travail bien. l'expérience vous aide mec.

Je veux dire autre chose, certaines erreurs ne dépendent pas de l'architecture du processeur. Ne vous inquiétez pas à ce sujet.

bonne chance. Ali Foroughi


3
2017-10-18 05:35



La ligne liée à "TryCathcWhen" me fait penser à une exception non gérée au démarrage, ou une exception est lancée dans un bloc catch au démarrage.

Voir votre code de démarrage serait utile.


3
2017-10-25 07:22