XamlParseException après le déploiement de projet WPF

https://stackoverflow.com/questions/4615597

26-09-2019
|

Question

Je suis en train de déployer mon application WPF, je créé un projet d'installation à l'aide du programme d'installation Wizard.The uniquement Sortie du projet I ajouté était primaire. Après avoir construit cela et l'installation du programme, dès que je clique sur le exe sur mon bureau, je reçois un pop up qui dit « Mon programme» a cessé de fonctionner », alors je clique déboguer le programme et je vois

Une exception non gérée du type 'System.Windows.Markup.XamlParseException' est produite dans PresentationFramework.dll

Informations complémentaires: 'Set connectionId a lancé une exception.' Numéro de ligne '10' et la position de la ligne '9'.

Cette exception ne me pointe pas dans toutes les directions à ce qu'il faut corriger. il n'y a pas partout « connectionId » dans mon application.

J'avais déjà couru dans un XamlParseException à cause de mon NotifyIcon pour mon plateau de système, mais cela a été corrigé en ajoutant l'icône sur le chemin de mon exe. Je pensais que cela peut être le problème donc j'ajouté l'icône à mon projet d'installation, ainsi que tous les autres résultats du projet. Pas encore de travail.

Je sais que cela est une erreur vague, mais toute aide serait du tout apprécié, mon application ne fonctionnera pas du tout. Merci!

La solution

Ceci est normalement dû à ne pas avoir toutes les dépendances copiés à la sortie. Comme vous le dites le message d'erreur est pas très utile, mais je voudrais vérifier que votre application a toutes les dépendances nécessaires disponibles pour résoudre les types analysés.

Normalement, il suffit de définir une copie locale sur true pour les ensembles référencés, mais je l'ai connu quelques cas où les références eux-mêmes ensembles de référence, il peut donc être nécessaire d'ajouter explicitement ces références ainsi.

Mise à jour:

Ajout important par @ BENN1TH.

Si vous voulez voir ce qu'est un assemblage est nécessaire:

devenais le même type d'émission une fois que je l'avais publié et installé mon projet (fonctionnait très bien dans le débogage VS2013 Desktop, aucune erreur, etc.), mais utilisé les conseils donnés dans http://geekswithblogs.net/lbugnion/archive/2007/03/14/108728.aspx et vlan! projet installé fonctionnait ..

try

{
  InitializeComponent();
}
catch ( Exception ex )
{
  // Log error (including InnerExceptions!)
  // Handle exception
}

Autres conseils

Nettoyage et reconstruction de la solution pourrait aider!

J'ai eu ce problème avec une solution WPF dans VS2010. La solution contenait simple dll et un projet de test (ensemble au démarrage) pour tester la dll. Mon dll a été mis à x86 et mon projet de test a été mis à x64. Quand j'ai changé le projet de test pour x86 le problème a été résolu.

Si vous obtenez cette exception dans le débogueur vérifier l'élément InnerException de l'exception. Il peut vous donner un indice sur l'assemblage qui manque.

try

{
  InitializeComponent();
}
catch ( Exception ex )
{
  // Log error (including InnerExceptions!)
  // Handle exception
}

Je viens d'avoir un bon 4 heures à essayer de comprendre. Le mien a fini par être rien à voir avec le XAML! Avéré que ce fut une erreur mineure dans le code sous-jacent sur MainWindow initialize.

Si tout le reste échoue, vérifiez il

Nettoyage et la reconstruction du projet n'a pas été efficace pour moi.

Vous pouvez essayer de supprimer bin Directory reconstruire, je résolu mon problème de cette façon.

J'ai ce problème. Ce problème se produit en raison de Microsoft.Expression.Drawing.dll s'il vous plaît télécharger dll et ajouter une référence.

Je suis tombé sur ce lorsque vous travaillez avec plusieurs dll en cours d'exécution dans une application et les DLLs ont des versions différentes de la même dépendance chargée.

Nous fusionnons normalement les dll lors de notre version release pour éviter ce problème, mais nous le voyons si nous testons plus d'un ensemble de dll au cours du cycle de unmerged développement.

La solution pour tester un seul ensemble de dll non fusionnées, en utilisant des versions de libération fusionnées pour les autres dll qui ne sont pas testés, ou pour assurer que la dll dépendante est la même version pour les deux ensembles.

Je l'ai résolu ce problème en supprimant Signer l'assembly , ici:

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow