- Nachträglich durch die Entwickler-Ecke gelöscht -

Der Begriff Managed Code bezieht sich darauf, daß der vom Compiler daraus erzeugte Code von einer CLR VM ausgeführt wird (s.a. Common Language Infrastructure), während "unmanaged code" nativer Code ist, der direkt vom Prozessor ausgeführt wird.
(Durch die Verwendung vom Jitter, d.h. AOT Kompilierung bzw. mittels NGen wird schlußendlich natürlich auch .NET-Code nativ ausgeführt, s. Understanding .NET Just-In-Time Compilation!)

Also alle .NET Assemblies (d.h. auch dein eigener C#-Code) ist "managed", während native EXE/DLLs (z.B. mit C, C++ oder Delphi erstellt) "unmanaged" sind.

Und dann wiederum die dlls die beides sind (mixed Assemblies)

Einer dll einfach ansehen was sie ist also managed, unmanaged oder mixed geht eher nicht. Du kannst die (PE)Header untersuchen. Aber sobald noch obfuscation Tools ins Spiel kommen ist das auch wieder verschleiert und nicht unbedingt erkennbar.

Zitat:

Sind somit sämtliche Assemblies, die Visual Studio mit sich führt, "Managed"

Nein. Wenn du die Assemblies des Net Frameworks meinst sind da auch einige Mixed Assemblies dabei und die als Framework markierten Assemblies haben aus Optimierungsgründen sicher noch andere Möglichkeiten genutzt als die die uns zum programmieren damit aus Sicherheisgründen nicht zur Verfügung stehen.

Zitat:

und Klassen, die von mir kommen,

C# ja. Aber C++/Cli erzeugt z.B. potentiel gemischten Code.

Zitat:

sowie API Funktionen, die ich importiere, "Unmanaged"?

Eigentlich ja. Aber dein unmanaged Code den du lädst könnte natürlich wieder selbst eine Net. Runtime starten um managed Code auszuführen. Das könnte auch alles in einer dll stecken. Verückt bis wahnsinnnig aber möglich.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Vor allem zum Beispiel Handles, die du über unmanaged Aufrufe auf die Windows API bekommst.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ich würde IDisposable wie es historisch gedacht war und wie es heute oft eingesetzt wird anders beschreiben bzw. unterscheiden wollen.

Es war gedacht um unmanaged Resourcen freizugeben (nie um managed Resourcen dafür gibts ja denn GC). Da unmanaged Resourcen üblicherweise geteilte Resourcen sind braucht man ein deterministisches Verhalten wann denn eine Resource freigegeben wird (Standardbeispiel Files) damit verschiedene Prozesse sich die auch vernünftig teilen können. Also eine Methode die man zum richtigen Zeitpunkt aufrufen kann anstatt es einem Algorithmus zu überlassen der das nach irgendwelchen allgemeinen Regeln irgendwann tut. An der Stelle beginnt es dann vom ursprünglichen Gedanken abzuweichen. Denn das Problem das etwas zu einem deterministischen Zeitpunkt passieren muß kann man genauso in einer reinen managed Umgebung haben. Dehalb sieht man oft einen ~Mißbrauch~ von IDisposable der nichts mehr mit unmanaged Resourcen zu tun hat sondern oft nicht mal mehr mit dem freigeben von irgendwas sondern eher der Zugangskontrolle zu Resourcen entspricht was man in anderem Kontexts mit Locks/Mutexen/Semaphoren etc. gelöst hätte.

Insofern würde ich heute IDisposable als ein Muster für Klassen erklären das nicht nur die deterministische Lebenszeit einer Resource steuert sondern auch den deterministischen Zugang zu einer Resource egal ob managed oder unmanaged.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Zitat:

Demnach sollte es so umgesetzt werden sollen wie in Delphi? Damit hätte ich auch meine Freude.

Was soll wie in Delphi umgesetzt werden

- Nachträglich durch die Entwickler-Ecke gelöscht -

Du verwechselst gerade Objekte mit Ressourcen. Ein Objekt ist keine Ressource. Ein Objekt kann aber möglicherweise eine Ressource enthalten/kapseln.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Meine Definition von Resource wäre es ist begrenzt oder sonstwie eingeschränkt und wird geteilt.
Wobei es in .Net eine besondere Resource gibt um die man sich nicht kümmern muß halt Memory. Wen ich im Context von C# von Resource spreche ist also nie Memory gemeint.

Zitat:

Dann sind Ressourcen doch nur Grafiken, Fonts, Dateien ... , und Objekte wiederum eine imageList, textBox ... ?!

Jein

Hast du eine Graphik im Speicher erfunden und existiert nicht auf Platte ist keine Resource in Verwendung es ist einfach ein Objekt das eine Graphik darstellt ohne benutzte Resource dahinter. Ist sie gebunden an ein File dann kann dieses zumindest potentiell mit anderen Prozessen geteilt werden heißt ich brauche deterministisches Verhalten für die ~hinter~ dem Image Objekt versteckte File Resource nicht für das Image Objekt.

Genauso Jein für TextBoxen. In Winforms steckt ein Common Control aus dem Kernel dahinter. Im TextBox Control steckt somit eine Resource die man rechtzeitig freigeben sollen. UI Handles sind begrenzt udn Winfomrs Control haben daher eine Dispose Methode. WPF zeichnet selber ein einzelnes Control verwaltet also nur Speicher und hat keine direkte Resourcenabhängigkeit daher brauchts da kein Dispose.

Zitat:

Sind denn Objekte innerhalb eines Objektes nicht irgendwie auch Ressourcen?

Wenn sie nur Speicher belegen nein. Wenn diese enthaltenen Objekte wiederum eine Resource benötigen dann benötigen sie eine Resource. Sie selber sind aber dann immer noch keine Resource. Objekte können Resourcen brauchen sie selbst sind aber keine.

Resourcen wären also Files, Ports etc. alles was in der Windows API durch Handles dargestellt wäre. Es könnten aber auch zum Beispiel Datenbank Connections sein also allgemein Systeme die dir etwas bereitstellen das begrenzt und/oder teilbar mit anderen Prozessen ist unabhängig vom Windows Subsystem.

- Nachträglich durch die Entwickler-Ecke gelöscht -