ClickOnce veröffentlicht durch NuGet installierte DLL nicht - Versionskonflikt?
Guten Vormittag,
folgende Situation:
Ich habe mehrere DLLs, davon sind ein paar .NET Standard 2.0 und die Anderen .NET 4.6.1
Nun brauche ich in einem .NET Standard Projekt das NuGet-Package "System.ComponentModel.Annotations", genauso auch in mehreren .NET 4.6.1 Projekten.
Das ganze Projekt wird mit ClickOnce verteilt.
Wenn ich aus VisualStudio heraus starte:
Alles funktioniert, keine Probleme
Wenn ich mit ClickOnce veröffentliche und dann die veröffentlichte Version starte:
Alles funktioniert, zumindest anfangs. In einzelnen Dialogen braucht er die System.ComponentModel.Annotations.dll und da zeigt er mir dann an, dass er diese Datei in der Version 4.2.0.0 nicht finden kann. Das stimmt auch, die Datei fehlt in dem Ordner, wenn ich sie manuell dorthin lege, funktioniert alles.
Wenn ich mir in den Projekt-Eigenschaften unter "Veröffentlichen" die durch "Anwendungsdateien..." angezeigte Liste anschaue, taucht diese DLL dort auch nicht auf.
Mein QuickFix, damit es erst einmal funktioniert:
Ich nehme die System.ComponentModel.Annotations.dll als Datei im Projekt auf, stelle als Buildvorgang "Inhalt" ein und lasse sie immer kopieren.
Dadurch taucht sie unter "Anwendungsdateien" auf und wird auch mit veröffentlicht.
Das funktioniert und vorerst kann ich das so lassen, aber das kann doch nicht richtig sein?
Ich habe auch extra nochmal das Package für das Projekt, das gestartet/veröffentlicht wird, installiert, das hat aber nichts gebracht.
VisualStudio-Neustart und bin/obj Ordner löschen hat auch nichts geholfen, diese DLL taucht nicht in den Anwendungsdateien auf.
Hat jemand eine Idee, woran das liegen kann und wie ich das Problem "richtig" beheben kann?
Meine Theorie ist, dass es mit einem Versionskonflikt zusammenhängt.
Wenn ich mir eine .NET 4.6.1 DLL im Decompiler anschaue, zeigt er mir an, dass er die Datei in der Version 4.0.0.0 erwartet.
Wenn ich mir eine .NET Standard DLL im Decompiler anschaue, wird die DLL mit der Version 4.2.0.0 referenziert.
Bei beiden Projekten ist das Package in der selben Version installiert.
Daher gleich die nächste Frage:
Warum bekomme ich bei demselben Package in der selben Version für unterschiedliche Zielframeworks (.NET 4.6.1 und .NET Standard 2.0) unterschiedliche Versionen der System.ComponentModel.Annotations.dll (4.0.0.0 und 4.2.0.0) installiert?
Gruß
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Moin Palladin,
ich hatte das Problem vor ein paar Wochen auch, bin aber leider auch nur auf deinen Workaround gekommen.
Bei mir fehlte unter anderem libSkiaSharp.dll.
Der Grund dafür interessiert mich brennend.
Das ist schon mal schön zu wissen, dass ich nicht der Einzige bin, der damit Probleme hat.
Dann hab ich schon mal kein allzu großes Brett vor dem Kopf 😄
Wenn ich ganz ehrlich bin, hab ich schon öfter darüber nachgedacht, ein eigenes Update-Tool zu basteln.
Da wäre denkbar, dass es auf einem Server einen Ordner gibt, in dem die verschiedenen Versionen liegen. Das lokale Update-Tool gleicht die lokale Version mit der Server-Version ab (welche Datei existiert bzw. existiert nicht und Datei-Hashes) und löscht bzw. aktualisiert die Inhalte.
So furchtbar kompliziert sollte das ja nicht sein, warum ist ClickOnce da so merkwürdig?
Und ja, Sicherheit hab ich außer Acht gelassen, wird ja sowieso nur intern genutzt - falls jemand meckern will.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Hi,
bevor du das selbst machst - schau dir mal https://github.com/github-graveyard/updateSystem.NET an. (Liegt zwar auf dem Friedhof - funktioniert aber bisher Klasse und bietet auch RSA-Verschlüsselung)
LG
Schau ich mir an, danke.
Wobei ich mich nicht ganz wohl dabei fühle, ein Tool zu verwenden, das seit Jahren tot und sogar die Website offline ist.
Muss ich mir noch überlegen, wie ich damit umgehe, aber aus dem Code lassen sich bestimmt einige nützliche Ideen ableiten - falls ich etwas eigenes baue.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Muss ich mir anschauen, danke.
Wir haben leider auch noch zwei wichtige Punkte, die das können muss:*Es darf keine Admin-Rechte brauchen. Wo die eigentliche Software liegt, ist mir herzlich egal, Hauptsache man kann sie mit möglichst wenig Rechten updaten und ausführen. ClickOnce macht das ganz schön, da liegt die ganze Anwendung irgendwo unter AppData. *Die Updates sind Pflicht und können nicht abgebrochen oder übersprungen werden. Bei ClickOnce kann man es überspringen, leider kommt das immer wieder vor, dass einzelne "schlaue" Leute die Updates überspringen, weil sie nicht darauf warten wollen, und sich dann wundern, dass irgendetwas nicht so tut wie es soll.
Mal schauen, ob nUpdate das kann.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Ohne Adminrechte kann keine Installation stattfinden, die sich auf irgendeiner Shared Location befindet.
Weder auf dem Dateisystem noch in der Registry.
Daher bleibt Dir bei einer solchen Installation immer nur das Userverzeichnis - mit all den Nachteilen.
Bei Microsoft findet man aber schon länger einen völlig neuen Installer:
https://github.com/Microsoft/msix-packaging
Wurde auch gestern beim Windows Developer Day vorgestellt.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ich hab wieder das gleiche Problem gehabt, dass eine einzelne DDL nicht in der "Anwendungsdateien"-Liste von ClickOnce auf taucht. Auch das hinzufügen der DLL als Inhalt hat nicht geholfen. Daher habe ich etwas weiter gesucht und das gefunden:
https://github.com/dotnet/standard/issues/529
Der ganz oben beschriebene Workaround hat bei mir nicht funktioniert, genauso wenig wie die anderen Workarounds. Scheinbar ist das ein bekannter Bug in ClickOnce, an dessen Behebung Microsoft bereits arbeitet.
Das letzte, was Jose Perez Rodriguez geschrieben hat, ist dieser Kommentar:
No updates on the fix, since we are still waiting for VS 15.8.
You can check the above comment from @onovotny which provided a possible workaround:
>
Und das wiederum verlinkt auf:
@NArnott What if you use a glob? I had to do something similar, for similar reasons, for the WAP packaging project for Desktop Bridge apps. Adding the entire output directory of the app as content, with the right Link path, did the trick:
<Content Include="..\PackageExplorer\bin\$(Configuration)\net461\**\*.dll"> <Link>NuGetPackageExplorer\%(RecursiveDir)%(Filename)%(Extension)</Link> </Content>
Dieser Workaround hat bei mir tatsächlich funktioniert. Ich musste zwar in den Anwendungsdateien einige weitere .NET-DLLs, die alle als "Erforderliche Komponente" markiert wurden, wieder einschließen, aber das kann man verkraften.
Das nur als Info, wenn jemand ähnlich verzweifelt wie ich nach eine Lösung sucht 😄
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.