XamlParseException dopo la distribuzione del progetto WPF

Ho cercato di distribuire la mia app WPF, ho creato un progetto di installazione utilizzando l’installazione guidata. L’unico output di progetto che ho aggiunto era primario. Dopo aver creato questo e installato il programma, non appena clicco l’exe sul mio desktop ottengo un pop-up che dice “Il mio programma ha smesso di funzionare”, quindi faccio clic su Debug the Program e vedo

Si è verificata un’eccezione non gestita di tipo “System.Windows.Markup.XamlParseException” in PresentationFramework.dll

Ulteriori informazioni: ‘Set connectionId ha gettato un’eccezione’. Numero riga ’10’ e posizione linea ‘9’.

Questa eccezione non mi indica in alcun modo su cosa correggere. non c’è “connectionId” in nessuna parte della mia app.

In precedenza avevo eseguito una XAMLParseException a causa del mio NotifyIcon per la barra delle applicazioni, ma ciò è stato risolto aggiungendo l’icona al percorso del mio exe. Ho pensato che questo potesse essere il problema, quindi ho aggiunto l’icona al mio Progetto di installazione, insieme a tutti gli altri Output di progetto. Continua a non funzionare.

So che questo è un errore vago, ma qualsiasi aiuto sarebbe apprezzato, la mia app non funzionerà affatto. Grazie!

Ciò è normalmente causato dal non aver copiato tutte le dipendenze nell’output. Come dici tu il messaggio di errore non è molto utile, ma vorrei verificare che l’applicazione abbia tutte le dipendenze necessarie per risolvere i tipi analizzati.

Normalmente è sufficiente impostare Copy Local su true per gli assembly referenziati, ma ho riscontrato alcuni casi in cui i riferimenti stessi fanno riferimento agli assembly, quindi può essere necessario aggiungere anche quei riferimenti in modo esplicito.

Aggiornare:

Aggiunta importante di @ BENN1TH.

Se vuoi vedere cosa è necessario un assemblaggio:

Stavo ricevendo lo stesso tipo di problema una volta che avevo pubblicato e installato il mio progetto (funzionava bene nel desktop di debug VS2013, nessun errore, ecc.) Ma usavo il consiglio in http://geekswithblogs.net/lbugnion/archive/2007/03/ 14 / 108728.aspx e wham ! progetto installato stava funzionando ..

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

La pulizia e la ricostruzione della soluzione potrebbero aiutare!

Ho avuto questo problema con una soluzione WPF in VS2010. La soluzione conteneva una semplice dll e un progetto di test (impostato su avvio) per testare la dll. La mia DLL era impostata su x86 e il mio progetto di test era impostato su x64. Quando ho cambiato il progetto di test in x86 il problema è stato risolto.

Se ottieni questa eccezione nel debugger controlla il membro InnerException dell’eccezione. Potrebbe darti un suggerimento su quale assembly manca.

Stavo ricevendo lo stesso tipo di problema una volta che avevo pubblicato e installato il mio progetto (funzionava bene nel desktop di debug VS2013, nessun errore, ecc.) Ma usavo il consiglio in http://geekswithblogs.net/lbugnion/archive/2007/03/ 14 / 108728.aspx e wham ! progetto installato stava funzionando ..

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

Ho avuto solo 4 ore buone cercando di capirlo. Il mio ha finito per non avere nulla a che fare con lo xaml! Si è scoperto che si trattava di un errore minore nel codice dietro all’inizializzazione di MainWindow.

Se tutto il resto fallisce, controlla lì

La pulizia e la ricostruzione del progetto non sono state efficaci per me.

Puoi provare a eliminare la directory bin e quindi ribuild, ho risolto il mio problema in questo modo.

Ho questo problema Questo problema si verifica a causa di Microsoft.Expression.Drawing.dll si prega di scaricare DLL e aggiungere riferimento.

Mi sono imbattuto in questo quando si lavora con più dll in esecuzione all’interno di un’applicazione e quelle DLL hanno versioni diverse della stessa dipendenza caricate.

Normalmente uniamo le DLL durante la nostra versione di rilascio per prevenire questo problema, ma lo vediamo se testiamo più di un set di dll non sommerse durante il ciclo di sviluppo.

La soluzione è quella di testare solo una serie di dll non raggruppate, utilizzando versioni con versione unificata per le altre DLL che non vengono testate o per garantire che la dll dipendente sia la stessa versione per entrambi i set.

Ho risolto questo problema rimuovendo Sign the assembly , qui:

inserisci la descrizione dell'immagine qui