C# Beziehung: Assembly - Programm

[TheRepatriate]

Hallo zusammen,

ich habe eine Verständnisfrage, weil ich mich gerade mit der Theorie von C# auseinandersetze. Die Frage zielt dabei eher auf die Grundlagen des .Net Frameworks ab.
Was genau ist der Unterschied, beziehungsweise das Verhältnis zwischen einer Assembly und einem Programm?

Eine Assembly ist ja eine Ausführbare Datei (Exe, DLL) und liegt in Intermediate Language vor, muss also nochmal während der Laufzeit kompiliert werden.
Ist das Kompilat dann das Programm?

Konkret frage ich mich das, weil ich vorher Programme und Assemblies gleichgesetzt habe.
Der Satz "Assemblies können Side by side geladen werden -> ein Programm kann gleichzeitig verschiedene Versionen einer Assemblie laden" wiederspricht dieser Vorstellung.

Daher wollte ich fragen, ob mir jemand den genauen Unterschied, beziehungsweise das Verhältnis von Assembly zu Programm erklären könnte?

Vielen Dank im Voraus!!!

 

[F_GXdx]

Hi,

also, der Begriff Assembly ist IMHO etwas schwammig und bezeichnet zwei Dinge:

1) Ein ausführbares Programm
2) Eine Programmbibliothek

Meiner Meinung nach überwiegt aber 2. Ein Assembly hat allerdings immer die Eigenschaft, dass sie versioniert ist (Versionsnummer hat), sowie, dass sie in CIL geschrieben ist, also .NET Zwischencode (bzw. dorthin compiliert wurde, die ursprüngliche Originalsprache kann dabei beliebig sein, solange nur ein Compiler nach CIL existiert). Nur die Ausführbarkeit ist nicht notwendigerweise Kriterium, aber eben auch nicht Ausschlusskriterium.

Um zu deiner Kernfrage vorzustoßen: Man könnte sich zB eine Grafikbibliothek vorstellen, die heißt A. Die Autoren entwickeln an dieser Bibliothek und werfen im Laufe dessen ein Feature raus. Du kannst dann in deinem Programm die Bibliothek A in Version 0.1 und 0.2 laden, und aus der alten Bibliothek eben das nehmen was du brauchst, und aus der neuen Bibliothek den Rest. Das wäre bei Java zum Beispiel nicht möglich, ohne einen Haufen Zeug umzubenennen, denn dort ist es bisher nicht vorgesehen, dieselbe Bibliothek in verschiedenen Versionen zu benutzen.

Tatsächlich ist es so, dass manche Software zwingend alte .NET Versionen braucht, da selbst .NET-Kernbibliotheken dieses "Problem" aufzuweisen scheinen.

Bin leider selbst kein .NET Entwickler, habe mich nur im wissenschaftlichen Rahmen kurz damit beschäftigt, daher ist mein Wissen eher theoretischer Natur.

Ergänzung (18. März 2012)

Noch ein Nachtrag: Es ist ja bei .NET auch so, dass Assemblies, die man für sein Programm verwendet, in den Global Assembly Cache kommen (sofern nicht anders spezifiziert, zB im Programmordner liegen). Das heißt, prinzipiell kann man - wenn man eine Assembly-Bib verwendet - das Programm auch ohne die Bib ausliefern und es dem User überlassen, sich diese zu besorgen. Wenn die Bibliothek hinreichend bekannt ist, könnte das manchmal Sinn machen (zB die .NET Kernbibliotheken selbst, aber eventuell zB auch GtK Sharp etc.).

Wenn ich aber zB bei Java eine Bib verwende, wäre es höchst unklug, sie nicht mit auszuliefern, eben wegen der Versionierung. Daher ist das IMHO auch gar nicht möglich/vorgesehen.

Wenn nämlich der .NET User die Bib sucht und downloadet, muss er zwingend Bib-A-Version-0.1 laden und installieren, bei Java müsste er nur Bib-A finden. Es ist aber in höchstem Maße unwahrscheinlich, dass dies nicht zu Problemen führt, da sich Bibliotheken logischerweise ständig weiterentwickeln. Und zwar nicht nur im Sinne, dass sich Sachen dazuentwickeln, was ja nicht stören würde, sondern auch, dass sich alte Sachen verändern, was natürlich zu Konflikten führt bis hin zur Unausführbarkeit (semantische vs. syntaktische Veränderungen).

Ergänzung (18. März 2012)

Sorry für die vielen Edits, aber ich wollte jetzt einfach mal eine ausführliche Antwort posten und das Thema ist nicht ganz unkomplex

Ergänzung (18. März 2012)

Gerade kommt mir, dass es natürlich möglich ist, in Java Bibliotheken zu versionieren, du musst nur ne JAR-Datei mit Manifest machen.

 

[holy]

In der Regel bestehen Anwendungen aus mehreren Komponenten: Einer ausführbaren Datei und mehreren DLLs. Wenn man nun eine Versionsnummer für die Anwendung vergeben möchte, muss man Buch über die Versionen der einzelnen DLLs als auch der EXE-Datei führen, damit man diesen Versionsstand später wiederherstellen kann (etwa zur Fehlersuche). Dies wird bei Anwendungen, die aus vielen Komponenten bestehen schnell unübersichtlich und erschwert damit Wartung und Pflege der Anwendung.

Die CLR erlaubt es nun, EXE-Datei und DLLs zu einem Paket zu gruppieren und die Versionierung gegen dieses Paket durchzuführen. Ein solches Paket wird mit Assembly bezeichnet und die darin enthalten Dateien nennt man Module. Für die Zuordnung zwischen Modulen und Assemblies sorgen meistens die .NET
Compiler. Standardmäßig wird beim Kompilieren für jedes Modul ein eigenes Assembly erstellt (Bild 5.1 zeigt diesen Zusammenhang).

Quelle: MSDN

Jetzt ersetze das Wort 'Anwendung' durch 'Programm' und du hast deine Beziehung.
Falls dir der Vergleich zu Java hilft: ein Assembly entspricht in etwa einem jar-Paket.

Zu meinem Vorposter:

..., sowie, dass sie in CIL geschrieben ist, also .NET Zwischencode (bzw. dorthin compiliert wurde, die ursprüngliche Originalsprache kann dabei beliebig sein, solange nur ein Compiler nach CIL existiert).

Alles vor den Klammern ist falsch

Tatsächlich ist es so, dass manche Software zwingend alte .NET Versionen braucht, da selbst .NET-Kernbibliotheken dieses "Problem" aufzuweisen scheinen.

Es gibt einen Unterschied zwischen der CLR Version und .NET Version. Siehe hier.
Die verschiedenen CLR Versionen werden unabhängig von einander installiert. D.h. sollte nur .NET 4 installiert sein, kann man trotzdem keinen .NET3.5 Code ausführen, der CLR2 Assemblies referenziert.
Das ist aber kein "Problem", sondern genau das Szenario aus deinem Beispiel mit der Grafikbibliothek A (siehe strong name assemblies unten).

Es ist ja bei .NET auch so, dass Assemblies, die man für sein Programm verwendet, in den Global Assembly Cache kommen (sofern nicht anders spezifiziert, zB im Programmordner liegen). Das heißt, prinzipiell kann man - wenn man eine Assembly-Bib verwendet - das Programm auch ohne die Bib ausliefern und es dem User überlassen, sich diese zu besorgen. Wenn die Bibliothek hinreichend bekannt ist, könnte das manchmal Sinn machen (zB die .NET Kernbibliotheken selbst, aber eventuell zB auch GtK Sharp etc.).

Der GAC stellt Assemblies systemweit zur Verfügung. Das ist seine Aufgabe.
Dort landet auch nichts automatisch. Strong Name Assemblies müssen manuell (oder per Installer) dort abgelegt werden. Wenn es sich nicht grade um eine Entwicklungsumgebung handelt, macht das nur in den wenigsten Fällen Sinn.

 

[F_GXdx]

Alles vor den Klammern ist falsch

Nein, stimmt schon alles

Natürlich wird niemand direkt in CIL programmieren, aber möglich wäre es auch

 

[TheRepatriate]

Danke für die Antworten! Denke jetzt hab ichs einigermaßen verstanden