Guten Nachmittag,

wir nutzen für die Verteilung einer ausschließlich intern genutzte Software ClickOnce.
Seit einigen Wochen macht das jedoch Probleme, dass ich kein Update machen kann, weil die neue Version nicht gestartet werden kann.

Der Ablauf ist also wie folgt:
- Ich aktualisiere die Anwendung wie gewohnt aus Visual Studio heraus
- Ein Mitarbeiter (in diesem Fall ich) startet die Anwendung und ClickOnce aktualisiert automatisch
- Es passiert nichts mehr - zumindest sieht das so aus

Im Eventlog von Windows gibt danach zwei Fehler-Einträge:

Fehler

Anwendung: applaunch.exe Frameworkversion: v4.0.30319 Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet. Ausnahmeinformationen: System.MethodAccessException bei System.RuntimeMethodHandle.PerformSecurityCheck(System.Object, System.RuntimeMethodHandleInternal, System.RuntimeType, UInt32) bei System.RuntimeMethodHandle.PerformSecurityCheck(System.Object, System.IRuntimeMethodInfo, System.RuntimeType, UInt32) bei System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo) bei DevExpress.Xpf.Core.ThemeManager.SubscribeApplicationThemeNameChanged() bei DevExpress.Xpf.Core.ThemeManager.Initialize() bei DevExpress.Xpf.Utils.ModuleInitializer.Initialize() bei <Module>..cctor() Ausnahmeinformationen: System.Windows.Markup.XamlParseException bei System.Windows.Markup.WpfXamlLoader.Load(System.Xaml.XamlReader, System.Xaml.IXamlObjectWriterFactory, Boolean, System.Object, System.Xaml.XamlObjectWriterSettings, System.Uri) bei System.Windows.Markup.WpfXamlLoader.LoadBaml(System.Xaml.XamlReader, Boolean, System.Object, System.Xaml.Permissions.XamlAccessLevel, System.Uri) bei System.Windows.Markup.XamlReader.LoadBaml(System.IO.Stream, System.Windows.Markup.ParserContext, System.Object, Boolean) bei System.Windows.Application.LoadComponent(System.Object, System.Uri) bei MyCoolApp.App.InitializeComponent() bei MyCoolApp.App.Main() bei System.AppDomain._nExecuteAssembly(System.Reflection.RuntimeAssembly, System.String[]) bei System.AppDomain.nExecuteAssembly(System.Reflection.RuntimeAssembly, System.String[]) bei System.Runtime.Hosting.ManifestRunner.Run(Boolean) bei System.Runtime.Hosting.ManifestRunner.NewThreadRunner() bei System.Threading.ThreadHelper.ThreadStart_Context(System.Object) bei System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) bei System.Threading.ThreadHelper.ThreadStart()

Fehler

Name der fehlerhaften Anwendung: applaunch.exe, Version: 4.7.3062.0, Zeitstempel: 0x5ab950ef Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.16299.611, Zeitstempel: 0x966d0f68 Ausnahmecode: 0xe0434352 Fehleroffset: 0x00104172 ID des fehlerhaften Prozesses: 0x3de8 Startzeit der fehlerhaften Anwendung: 0x01d4dd99d1f5bf00 Pfad der fehlerhaften Anwendung: C:\Windows\Microsoft.NET\Framework\v4.0.30319\applaunch.exe Pfad des fehlerhaften Moduls: C:\windows\System32\KERNELBASE.dll Berichtskennung: deab60fe-3cbb-4dc8-8578-cfbc015d3bd9 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Bisher konnte ich das Problem immer so "umgehen", dass ich aus dem von ClickOnce verwalteten "Application Files"-Ordner das letzte Update raus lösche und die .application-Datei mit der von der "neuen alten" Datei überschreibe. So kann zumindest die alte Version weiterhin verwendet werden, aber das Update bekomme ich immer noch nicht verteilt.

Mir ist nicht bekannt, dass ich irgendetwas geändert haben sollte, was damit zusammen hängen könnte. Wenn ich die Anwendung im "Application Files"-Ordner suche und von dort die neuste Version starte, funktioniert auch alles problemlos.

Eventuell hilfreich ist noch:
In der Fehlermeldung steht die .NET-Version 4.0, die Anwendung nutzt aber 4.6.1
Das ist allerdings schon länger so und vor 4.6.1 wurde 4.5.2 verwendet.


Hat jemand eine Idee, was das Problem ist, oder zumindest eine Idee, wo bzw. wie ich mit der Fehlersuche beginnen kann?

Ich hoffe, jemand kann mir irgendwie helfen :)

Hat niemand eine Idee, was das sein könnte?

Oder eine Idee, wie ich mehr Infos bekommen kann?
Die exe ist ja auch kein .NET, ich kann also auch nicht debuggen :/

Hallo Palladin, hast das Problem inzwischen behoben?
Was war denn die Ursache dafür?

Ich habe ein ähnliches Problem. Habe eine Appliaktion, mit mehreren Projekten, habe ich auch schon länger am laufen. Jetzt habe ich ein zusätzliches Projekt eingebunden, weil ich ein neues Feature eingebaut habe.
Dann habe ich die Applikation veröffentlicht, konnte diese aber nicht installieren, Deployment-Error.

Kann es sein, sobald man ein anderes Projekt hinzubindet oder nur eine Methode die eine andere EXE aufruft, das dann die Applikation sich nicht mehr automatisch mit einer neueren Version sich nicht mehr installiert?

Wenn das so wäre, muss mann ja jedes mal die Applikation auf den Rechnern deinstallieren und neu installieren, absolut unbrauchbar???
Hast du da eine Idee?

Das konkrete Problem hatte ich nicht mehr gelöst - zumindest soweit ich mich erinnere.
Ich weiß jedenfalls noch, dass ich nach einem ClickOnce-Problem (nicht das erste) mich dazu entschlossen habe, ClickOnce als Problem-Zeit-Fresser ganz abzuschaffen und habe dann auf Basis von AutoUpdater.NET eine Alternative eingeführt.

Ob das für dich auch der richtige Weg ist, kann ich dir nicht sagen, dazu bin ich zu lange aus dem Thema raus.
Du solltest dir aber in jedem Fall gut überlegen, bevor Du ganz umstellst, denn das bedeutet zwar weniger Probleme, allerdings machst Du gleichzeitig einiges an anderen Aufwänden und möglichen Problemen auf, die Du vermutlich gar nicht auf dem Schirm hast.

Bei uns war es eine Folge von mehreren Problemen, die jedes Mal viel Zeit gekostet haben und dass wir generell (auch aus anderen Gründen) nie ganz zufrieden mit ClickOnce waren.

Ok, danke erst mal für die Info.

Zitat von Palladin007

Ich weiß jedenfalls noch, dass ich nach einem ClickOnce-Problem (nicht das erste) mich dazu entschlossen habe, ClickOnce als Problem-Zeit-Fresser ganz abzuschaffen und habe dann auf Basis von AutoUpdater.NET eine Alternative eingeführt.

Ich habe mich kürzlich aus Gründen mit dem Thema beschäftigt und bin zu dem gleichen Ergebnis gekommen. War einfach einzubauen und läuft sauber.
Zusätzlich habe ich ein Deploy-Projekt gebaut, mit ich es mit einem Klick veröffentliche kann.