Autor Beitrag
ralph71
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Mo 16.01.17 16:25 
Hallo,

ich habe in eine Form einen ReportViewer eingebaut. Dieser greift brav auf einen zuvor erstellen Report (Report.rdlc) zu und stellt diesen fehlerfrei dar.
Wenn ich nun mein Projekt als Release "speichere" und dieses dann auf einem anderen PC starte, dann funktioniert die gesamte Anwendung incl der zusätzlich eingebundenen DLLs problemlos.
Möchte ich jedoch den Report aufrufen, fährt das Programm an die Wand. Im Release-Ordner sind jedoch alle Dateien enthalten....
Fehler:
Die Datei oder Assembly "Microsoft.ReportViewer.Common, Version....." oder eine Abhängigkeit davon wurde nicht gefunden.

Warum?

Vielen Dank!
Th69
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Moderator
Beiträge: 4764
Erhaltene Danke: 1052

Win10
C#, C++ (VS 2017/19/22)
BeitragVerfasst: Mo 16.01.17 16:57 
Hallo,

zuerst einmal im GAC ("\Windows\assembly") des anderen PCs schauen, ob die Datei dort vorhanden ist.
Und mit den beiden Tools Dependency Walker und .NET Dependency Walker kannst du die abhängigen DLLs (bzw. Assemblies) herausfinden (und ob diese dort auf dem Rechner fehlen).
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4700
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Mo 16.01.17 17:01 
Laut Doku gehört zum ReportViewer eine Runtime die mit deployed werden muß.

Deploying Reports and ReportViewer Controls


Moderiert von user profile iconTh69: URL-Titel hinzugefügt.
ralph71 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Mo 16.01.17 17:16 
Aha,
und das heißt jetzt:
* ich hab bei mir was installiert und weiß es nimmer (würde mich nicht wundern...)?
* der Release-Ordner alleine reicht nicht?
* ich benötige für Dritt-PCs eine Installationsroutine durch die Softwareverteilung?

-->
Ohje, ohje, ohje

?
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4700
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Mo 16.01.17 17:21 
Zitat:
* ich hab bei mir was installiert und weiß es nimmer (würde mich nicht wundern...)?

Du erinnerst dich daran Visual Studio installiert zu haben? :wink:
Zitat:
* der Release-Ordner alleine reicht nicht?

Laut Doku nein.
Zitat:
* ich benötige für Dritt-PCs eine Installationsroutine durch die Softwareverteilung?

Ich nenne sowas ein Setup. Klingt völlig normal.
jfheins
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 918
Erhaltene Danke: 158

Win 10
VS 2013, VS2015
BeitragVerfasst: Di 17.01.17 09:16 
Wenn dich die ganzen Assemblies stören, kannst du die auch in die exe mit integrieren: www.hanselman.com/bl...MergeAndMSBuild.aspx

Es gibt dafür auch (mindestens) ein nuget-Paket, welches du einfach nur einbinden musst.
ralph71 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Di 17.01.17 14:49 
Wenn ich das jetzt richtig verstehe, dann würde also das nuget die fehlenden Assemblies in den "Release-Ordner" schreiben?
Sorry, aber welches nuget wäre das dann (in der Hoffnung es auch bedienen zu können)?
Th69
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Moderator
Beiträge: 4764
Erhaltene Danke: 1052

Win10
C#, C++ (VS 2017/19/22)
BeitragVerfasst: Di 17.01.17 15:03 
Hallo,

Top 20 NuGet packages for ILMerge
Ich würde ersteinmal "MSBuild ILMerge task" empfehlen.

Es werden aber nicht die Assemblies in den bin-Ordner verschoben, sondern direkt in die EXE reingepackt.
jfheins
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 918
Erhaltene Danke: 158

Win 10
VS 2013, VS2015
BeitragVerfasst: Di 17.01.17 22:21 
Ich habe heute mal nachgeschaut, wir haben Costura.Fody verwendet.

Die benötigten Assemblies sollten bereits jetzt im Release-Ordner landen. das nuget-Pakt sogt lediglich dafür, dass diese nicht als separate Datei neben der exe liegen, sondern in die exe-Datei integriert werden.

Installation ist einfach: Du öffnest die Paket-Manager Konsole und tippst dort "Install-Package Costura.Fody" ein. Die Konsole erreichst du, indem du auf View > Other Windows > Packet Manager Console gehst. (ggf. entsprechend die deutschen Begriffe)
ralph71 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Mi 18.01.17 09:34 
Ich danke für die Antworten!

Ich habe das Costura.Fody importiert, die DLL eingebunden, das Release erstellt, festgestellt, dass die EXE deutlich größer ist, aber:
die Fehlermeldung bleibt: Die Datei oder Assembly "Microsoft.ReportViewer.Common, Version....." oder eine Abhängigkeit davon wurde nicht gefunden.

Jetzt wirds knifflig...
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4700
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Mi 18.01.17 11:09 
Bevor ihr euch dem Metaproblem des merging widmet wäre es auch eher hilfreich zu klären was die tatsächlich nötigen Abhängigkeiten sind.
Ich habe das jetzt nicht ergründet (habe den Reportviewer noch nie benutzt) aber wenn Microsoft sich einen extra deployment package dafür ausdenkt ist es sicher nicht nur dazu da die Assemblies zu kopieren die im Standardfall eh im bin Ordner landen. Dafür wäre das unnötig.

Also solltest du zuerst klären ob du alle bekannten Abhängigkeiten hast. Zumindest alle in der Doku erwähnten nötigen Assemblies. Das solltest du erst ungemergt probieren.
Wenn das geht kannst du dir immer noch überlegen ob das mergbar ist. Ich habe da so meine Zweifel. Es sind Microsoft Assemblies signiert mit dem Microsoft Schlüssel. Solltest du denn nicht zufällig haben sehe ich nicht wie das funktionieren soll. Der Loader wird die Signatur prüfen und die hast du nach dem mergen nicht mehr.
ralph71 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Do 19.01.17 10:51 
Hallo,

über den Veröffentlichungsassistenten in VS habe ich jetzt versucht die Anwendung zu veröffentlichen.

Unter den erforderlichen Komponenten kann "Microsoft.ReportViewer.Common, Version=12.0.0.0" nicht ausgewählt werden. Die dazu nötige Datei ReportViewer.msi habe ich mir besorgt. Eine Installation ist jedoch nicht möglich, weil es die CLR-Typen für SQL Server benötigt. D.h. diese müsste vorher installiert werden.....
Zudem gibts da noch das da: msdn.microsoft.com/d...ibrary/ms251723.aspx. Hier wird es eigentlich gut beschrieben. Es funktioniert aber nicht, weil die Komponenten nicht in den entsprechenden Versionen zur Verfügung gestellt werden.

Das kann doch unmöglich der Standardweg sein. Ich benutze im VS ein Default-Element um einen Bericht zu erstellen und muss dann für einen Deploy diesen Aufwand betreiben? Jetzt kann ich natürlich 1000 Sachen installieren, und irgendwann funktioniert es dann, aber für den "Masseneinsatz" kann das nicht der Weg sein

Elegant wäre es, wenn mir VS unter "Erforderliche Komponenten" die entsprechenden Einträge zur Verfügung stellen würde.

?
ralph71 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Do 19.01.17 11:32 
Habs!
Ursache: der Verweis "Microsoft.ReportViewer.Common" zeigt auf lokales Dateiverzeichnis (also C:\....).
Nach der Release-Erstellung findet er auf einem Dritt-Pc natürlich den Pfad nicht.
Lösung:
1. Verweis "Microsoft.ReportViewer.Common" löschen
2. über den nuget die Microsoft.ReportViewer.2015.Runtime installieren.
--> es wird automatisch ein neuer Verweise "Microsoft.ReportViewer.Common" generiert, der jetzt aber im Package ist.


Wenn man das jetzt verstanden hat, dann machen eure Antworten auch Sinn... :-))))