none
Visual Studio 2010 - Projekt veröffentlichen - beteiligte Dateien RRS feed

  • Frage

  • Hallo Forumsteilnehmer,

    in Visual Studio (2010) in den Projekteigenschaften gibt es ja den Bereich "Veröffentlichen -> Anwendungsdateien", wo für alle Verweise eine entsprechende Option ("Erforderliche Komponente, einschließen, etc.") gesetzt werden kann. Es gibt aber auch den Bereich "Verweise", wo man pro Verweis ja die Option "Lokale Kopie" wählen kann. Mir ist hier das Zusammenspiel nicht ganz klar. Beinhaltet das eine nicht irgendwie das andere?

    Konkret habe ich ein altes Windows Forms Projekt (VS2005) konvertiert zu einem Visual Studio 2010 Projekt. Dabei habe ich unter anderem das "Ziel Framework" auf ".NET Framework Version 4" umgestellt und alte Berichte, die auf Crystal Reports basiert waren, wurden umgebaut auf die im 4er Framework enthaltenen Reporting Services.

    Das Einspielen der neuen Version (Click-Once Update Feature) ist auf Testmaschinen natürlich erst mal gescheitert, z.T. weil die Framework Version nicht passt, z.T. aber auch eben wegen fehlenden oder nicht mehr passenden Verweisen, und aus diesem Grund habe ich die Liste der bislang eher wahllos gesetzten "copy to local" Verweise sowie die Einstellungen unter "Anwendungsdateien" mal etwas genauer angesehen...

    Wie verhält es sich mit dem eingangs beschriebenen Zusammenspiel der Einstellungsmöglichkeiten genau, kann mich hier jemand etwas aufklären?

    Und noch eine weitere, etwas konkretere Frage: Verweise auf z.B. "System", "System.Data", "System.Windows.Forms" machen mit der Option "Copy to local" doch eigentlich keine Sinn, oder? Die DLLs werden doch zwangsweise vom Framework bereitgestellt, oder? Die Option "Copy to local" macht doch eigentlich nur bei externen DLLs wie z.B. "MySql.Data" Sinn, oder?

    Danke im voraus und einen schönen Feiertag,

    Jan


    Mittwoch, 8. Mai 2013 16:24

Antworten

  • Hallo Jan,
    eine .NET-Assembly lässt sich nur übersetzen, wenn über References (Verweise) alle weiteren benötigten Assemblys dem Compiler bzw. MSBuild bekannt gemacht werden. In VB werden je nach Projektvorlage einige Verweise bereits direkt im angelegten Projekt gesetzt. Der Ablageort kann sowohl im GAC als auch außerhalb des GAC im Dateisystem sein. Das Zielsystem muss zur Ausführungszeit die referenzierten Assemblys finden. Wenn diese Assemblys nicht im Zielsystem vorhanden sind, müssen mit ausgeliefert werden. Beim Veröffentlichen gibt es da nur die Möglichkeit, diese im Zielsystem nicht vorhandenen Assemblies in den Anwendungsdateien zu vermerken. Das wird automatisch auf Basis der vbproj-Datei gemacht, in der die als lokale Kopie verzeichneten Assemblies vermerkt sind. Bei Assemblies, die nicht als lokale Kopie gekennzeichnet sind, wird davon ausgegangen, dass sie im Zielsystem vorhanden sind.
     
    Über separate Projekte (z.B. Setup) können bestimmte Assemblies (z.B. für den ReportViewer) auf dem Zielrechner installiert werden und dann als Voraussetzung (Prerequisities) markiert werden. Damit kann sichergestellt werden, dass bei Fehlen der Voraussetzungen diese installiert werden. Wenn so nicht gearbeitet wird und kein GAC-Deployment für weitere mitzuliefernde Assemblies erforderlich ist, dann können diese Assemblies auch als Anwendungsdateien mitgeliefert werden.
     
    Für die Dateien der betreffenden Frameworkversion kann auch in den Voraussetzungen (Prerequisities) der entsprechende Haken gesetzt werden und es wird geprüft, ob diese Frameworkversion auf dem Zielsystem installiert ist. Damit erübrigt sich natürlich “Copy to Loacl” usw. für z.B. “System.dll” usw.
     
    --
    Peter Fleischer
    • Als Antwort markiert Jan Kornblum Montag, 13. Mai 2013 08:01
    Mittwoch, 8. Mai 2013 17:12
  • Hallo Jan,

    Copy Local hat nichts mit dem Veröffentlichen zu tun.
    Siehe z. B.: Partitioning Your Code Base Through .NET Assemblies and Visual Studio Projects

    auch zu finden in: http://stackoverflow.com/questions/280751/what-is-the-best-practice-for-copy-local-and-with-project-references

    Für .NET Assemblies gilt: Da Visual Studio (ab 2008) unterschiedliche .NET Versionen verwenden kann (Multi-targeting), wird über die Reference Assemblies darauf verwiesen, die durch das eingestellte Framework des Projekts bestimmt wird.

    Bei der installierten Version wird die Assembly aus dem GAC verwendet, die durch die (erforderliche)  .NET Installation auf den (Kunden)-Rechner kommt.

    Was nun die Click-Once Bereitstellung angeht:
    Dort kann man die Voraussetzungen angeben, die für die Anwendung auf dem Rechner installiert werden müssen. Siehe u. a. Vorbedingungen für die Anwendungsbereitstellung

    Dafür sind i. d. R. administrative Rechte erforderlich, die für eine Click-Once Anwendung selbst nicht verfügbar sind. Ein Diskussion, wo es darum ging: VB 2008: Fehlermeldung beim Installieren einer Anwendung (Moral der Geschichte dort: Nie mehr installieren als man wirklich braucht ;)

    Gruß Elmar

    • Als Antwort markiert Jan Kornblum Montag, 13. Mai 2013 08:14
    Mittwoch, 8. Mai 2013 20:49
    Beantworter

Alle Antworten

  • Hallo Jan,
    eine .NET-Assembly lässt sich nur übersetzen, wenn über References (Verweise) alle weiteren benötigten Assemblys dem Compiler bzw. MSBuild bekannt gemacht werden. In VB werden je nach Projektvorlage einige Verweise bereits direkt im angelegten Projekt gesetzt. Der Ablageort kann sowohl im GAC als auch außerhalb des GAC im Dateisystem sein. Das Zielsystem muss zur Ausführungszeit die referenzierten Assemblys finden. Wenn diese Assemblys nicht im Zielsystem vorhanden sind, müssen mit ausgeliefert werden. Beim Veröffentlichen gibt es da nur die Möglichkeit, diese im Zielsystem nicht vorhandenen Assemblies in den Anwendungsdateien zu vermerken. Das wird automatisch auf Basis der vbproj-Datei gemacht, in der die als lokale Kopie verzeichneten Assemblies vermerkt sind. Bei Assemblies, die nicht als lokale Kopie gekennzeichnet sind, wird davon ausgegangen, dass sie im Zielsystem vorhanden sind.
     
    Über separate Projekte (z.B. Setup) können bestimmte Assemblies (z.B. für den ReportViewer) auf dem Zielrechner installiert werden und dann als Voraussetzung (Prerequisities) markiert werden. Damit kann sichergestellt werden, dass bei Fehlen der Voraussetzungen diese installiert werden. Wenn so nicht gearbeitet wird und kein GAC-Deployment für weitere mitzuliefernde Assemblies erforderlich ist, dann können diese Assemblies auch als Anwendungsdateien mitgeliefert werden.
     
    Für die Dateien der betreffenden Frameworkversion kann auch in den Voraussetzungen (Prerequisities) der entsprechende Haken gesetzt werden und es wird geprüft, ob diese Frameworkversion auf dem Zielsystem installiert ist. Damit erübrigt sich natürlich “Copy to Loacl” usw. für z.B. “System.dll” usw.
     
    --
    Peter Fleischer
    • Als Antwort markiert Jan Kornblum Montag, 13. Mai 2013 08:01
    Mittwoch, 8. Mai 2013 17:12
  • Hallo Jan,

    Copy Local hat nichts mit dem Veröffentlichen zu tun.
    Siehe z. B.: Partitioning Your Code Base Through .NET Assemblies and Visual Studio Projects

    auch zu finden in: http://stackoverflow.com/questions/280751/what-is-the-best-practice-for-copy-local-and-with-project-references

    Für .NET Assemblies gilt: Da Visual Studio (ab 2008) unterschiedliche .NET Versionen verwenden kann (Multi-targeting), wird über die Reference Assemblies darauf verwiesen, die durch das eingestellte Framework des Projekts bestimmt wird.

    Bei der installierten Version wird die Assembly aus dem GAC verwendet, die durch die (erforderliche)  .NET Installation auf den (Kunden)-Rechner kommt.

    Was nun die Click-Once Bereitstellung angeht:
    Dort kann man die Voraussetzungen angeben, die für die Anwendung auf dem Rechner installiert werden müssen. Siehe u. a. Vorbedingungen für die Anwendungsbereitstellung

    Dafür sind i. d. R. administrative Rechte erforderlich, die für eine Click-Once Anwendung selbst nicht verfügbar sind. Ein Diskussion, wo es darum ging: VB 2008: Fehlermeldung beim Installieren einer Anwendung (Moral der Geschichte dort: Nie mehr installieren als man wirklich braucht ;)

    Gruß Elmar

    • Als Antwort markiert Jan Kornblum Montag, 13. Mai 2013 08:14
    Mittwoch, 8. Mai 2013 20:49
    Beantworter
  • Morgen Peter,

    vielen Dank für diese ausführliche Antwort!

    Grüße, Jan

    Montag, 13. Mai 2013 08:01
  • Hallo Elmar,

    auch dir vielen Dank für diese ausführliche Erklärung! Jetzt geht es ans Ausprobieren...

    Viele Grüße
    Jan

    Montag, 13. Mai 2013 08:14
  • Hallo Peter,

    jetzt muss ich mich doch nochmal melden, denn ganz klar ist es mir immer noch nicht ;(

    Den ReportViewer habe ich unter "Erforderliche Komponenten" zunächst aktiviert und bei "Anwendungsdateien" auf "Erforderliche Komponente (Auto)" gestellt. Das sollte so ja nun funktionieren, jedoch scheitert der Download vom ReportViewer von der Herstellerwebsite auf allen Clients.

    Daher habe ich jetzt als Alternative den ReportViewer in den "erforderlichen Komponenten" nicht angekreuzt, dafür aber unter "Anwendungsdateien" alle 4 DLL's auf "Einschließen" gestellt. Das scheint auf verschiedenen Clients nun auch zu funktionieren.

    Nun die Frage: Warum funktioniert das Ganze nun, ohne dass die ReportViewer DLL's in den Verweisen auf "Copy to local" gestellt sind? Bzw. andersrum: Wann genau ist ein "Copy to local" notwendig"?

    Viele Grüße, Jan

     

     

     

    Montag, 13. Mai 2013 09:42
  • Hallo Jan,

    Copy Local spielt wie gesagt keine Rolle, wenn die Dateien im GAC landen, was beim ReportViewer der Fall ist - siehe Hinweis - denn der Global Assembly Cache hat Vorrang.

    Was den Report Viewer für 2010 angeht, scheint es einen Bug zu geben, siehe Connect
    sollte bei SP1 gefixt sein.

    Weiteres siehe Bereitstellen von Berichten und ReportViewer-Steuerelementen

    Will man sich nicht darauf verlassen, installiere den Report Viewer 2010 SP1 separat.

    Gruß Elmar

    Montag, 13. Mai 2013 10:23
    Beantworter
  • Hi Elmar,

    danke für das schnelle Feedback!

    Das mit dem Bug beim RV habe ich auch schon gefunden, aber noch keine wirkliche Lösung - ist auch egal, denn mit dem Inkludieren der DLL's bei den Anwendungsdateien funktioniert es ja auch...

    Deinen Hinweis zu den lokalen Kopien habe ich auch nochmal durchgelesen, trotzdem verstehe ich eines noch nicht:

    Hat ein "Einschließen" unter "Anwendungsdateien" denn nicht das gleiche zur Folge wie an dieser Stelle ein "Erforderliche Komponente" kombiniert mit "Lokale Kopie" unter Verweise? Sprich, dass die Datei ins Ausgabeverzeichnis der Anwendung kopiert wird und nicht im GAC vorhanden sein muss?

    Viele Grüße, Jan

    Montag, 13. Mai 2013 10:44
  • Hallo Jan,

    Grundlage für jede Assembly-Auflösung ist:
    So sucht Common Language Runtime nach Assemblys

    D. h. findet die Runtime einen starken Namen - bei den ReportViewer Komponenten der Fall - so wird der GAC bevorzugt. Gibt es keine Installation im GAC, so wird im lokalen Anwendungsverzeichnis gesucht.

    Somit gilt: Gibt es keine ReportViewer Installation auf dem lokalen Rechner kommen die Dateien aus dem Anwendungsverzeichnis (wenn vorhanden) zum Tragen.

    Gruß Elmar

    Montag, 13. Mai 2013 13:59
    Beantworter
  • Hi Elmar,

    danke. Nun aber nochmal zu der anderen Frage, in der Hoffnung, dass dir nicht der Geduldsfaden reisst ;)

    ---
    Hat ein "Einschließen" unter "Anwendungsdateien" denn nicht das gleiche zur Folge wie an dieser Stelle ein "Erforderliche Komponente" kombiniert mit "Lokale Kopie" unter Verweise?
    ---

    Sehe ich das richtig?

    Grüße, Jan

    Montag, 13. Mai 2013 15:29
  • Hi nochmal,

    also ich denke ich kann mir die Antwort selber geben ;) Die Bereiche "Veröffentlichen" und "Verweise" haben ja zuerst mal gar nichts miteinander zu tun.

    Wenn die Anwendung nicht über ClickOnce veröffentlicht wird, muss bei den Verweisen je nach Fall eben "Lokale Kopie" gesetzt sein, damit die Anwendung nach dem Kompilieren lauffähig ist.

    Wird die Anwendung allerdings über ClickOnce veröffentlicht, bewirkt eine Einstellung "Einschließen" unter "Anwendungsdaten" im Prinzip dasselbe, wie ein "lokale Kopie" bei "Verweisen" und letztere kann entfallen.

    Im Prinzip ist das also eine gewisse Überschneidung, je nachdem auf welchem Weg die Anwendung auf den Zielrechner kommen soll.

    Richtig?

    Grüße, Jan

    Montag, 13. Mai 2013 16:08
  • Hallo Jan,

    noch nicht so ganz.

    Lokale Kopie steuert - siehe ersten Beitrag - auch andere Dinge.

    ClickOnce wertet "Lokale Kopie" aus, um die Einstellungen für die Veröffentlichung zu bestimmen. Danach ist man frei sie anzupassen.

    Es ist also weniger eine Überschneidung als eine "Zusatzverwendung".

    Gruß Elmar

    Montag, 13. Mai 2013 18:03
    Beantworter