Jegliche .NET DLL in dotnet core verwendbar?

Hi zusammen,

ich beschäftige mich gerade mit den Unterschieden zwischen .net Framework und dotnet core, weil wir eine Migration überlegen.

Mir ist aufgefallen, das ist fast jede .net DLL via nuget in ein core projekt importieren kann und auch unsere eigenen Projekte-DLL importierbar (und auch funktionstüchtig) sind.

Ist das richtig so? Bzw. wo sind hier die Grenzen? Oder kann ich quasi alles in core verwenden, was nicht plattformspezifisch ist, bzw. auf eine GUI angewiesen ist?

Hi,

nun - jede DLL ist leider zu viel erwartet.

Jede DLL die in .NET Standard bzw. .NET Core verfügbar ist.

Es ist zwar richtig, dass extrem viele Libraries nun per .NET Standard verfügbar sind - aber es sind auch lange nicht alle.

Womit ich anfangs häufiger Probleme hatte betraf meist folgende Bereiche:

• Zeichnen
• Reflection
• teils Kryptografie
  (wobei ich gestehen muss, dass das teils etwas länger her ist - ich gehe davon aus, dass mittlerweile die API-Abdeckung vollständiger ist)

Grundlegend: Wenn ihr Projekte verwendet, die nicht wirklich aktiv gepflegt werden oder aufgrund API-Schwachstellen nicht portiert wurden kann das schon ein Problem werden. Wobei ich mittlerweile erwarten würde, dass .NET Standard und .NET Core ausreichend Möglichkeiten bieten um nicht bei der Portierung "stecken zu bleiben".

Vielen Dank für deine schnelle Antwort.

Was ist denn jetzt schon wieder dotnet Standard ? 😄

Das ist komplett an mir vorbei gegangen.

.NET Standard ist so das ziemlich wichtigste im .NET Ökosystem - und das schon einige Jahre.
Werf ein Blick in die Doku oder schau Dir die YouTube Videos von Immo Landwerth an.

Wenn Du das durch hast dann verstehst auch wieso viele Elemente nicht mehr Teil einer lokalen Installation sind sondern eben via NuGet kommt.

Hallo Christoph K.,

Was ist denn jetzt schon wieder dotnet Standard

Stell dir das als Schnittstelle / Interface vor, welches von den "Runtimes" (.NET Full, .NET Core, Mono, Xamarin, ...) implementiert wird.

den Unterschieden zwischen .net Framework und dotnet core

Wirklich ins Details sollten wir in diesem Thread nicht geben, da es zum Einen zu umfangreich wäre und zum Anderen es genügend Info zu finden gibt 😉
Kurz: .NET Core ist die plattformunabhängige Reinkarnation mit hoher API-Kompatibilität des .NET Frameworks und ab .NET 5 die alleinige .NET Plattform (obwohl .NET Full noch lange unterstützt bleibt).

fast jede .net DLL via nuget in ein core projekt importieren

Das Konzept dahinter nennt sich Multi-Targeting. D.h. der gleiche Code wird für verschiedene "Target" kompiliert und im NuGet-Paket verpackt. Beim Hinzufügen vom Paket wird je nach "Target" vom Tooling die passende Referenz verwendet.

Bei eurem Projekt funktioniert das deshalb, weil der Ersteller des NuGet-Pakets es richtig gemacht hat.
Ein reines .NET 4.5 Paket würde beispielsweise nicht funktionieren. Entweder -- so wie Taipi88 erwähnt hat -- basiert es auf .NET Standard od. hat einen entsprechenden .NET Core Target im Paket.

Für neu erstellte Libraries ist es daher auch ratsam auf .NET Standard zu setzen, da diese überall dort lauffähig sind, wo eine Runtime diesen Standard (~ Interface) implementiert.

Oder kann ich quasi alles in core verwenden, was nicht plattformspezifisch ist,

Der Begriff "Plattform" ist leider nicht eindeutig definiert, denn dieser kann bezogen auf Betriebssystem, bezogen auf Technologie, etc. werden.
.NET Core ist auch eine Plattform bzw. ein Target im obigne Sinn von Multi-Targeting.
Es kann alles in .NET Core verwendet werden das in .NET Core lauffähig ist, soll konkreter heißen: Referenzen die entweder .NET Standard (da .NET Core den .NET Standard implementiert) od. .NET Core selbst sind.

bzw. auf eine GUI angewiesen ist?

WinForms und WPF werden seit .NET Core 3.0 auch unterstützt.

Obwohl .NET Core plattformunabhägig im Sinne von Betriebssystemen erstellt wurde (daher läuft es auf Windows, Linux, OSX, ...) kann "ganz normal" auf native Komponenten zugegriffen werden. Speziell für Windows gibt es auch eine "Compatibility Pack" das den Zugriff auf die Windows-Registry udgl. ermöglicht, da es dafür kein direktes Gegenstück in anderen Betriebssystemen gibt.

weil wir eine Migration überlegen.

Schau dir dabei auch The .NET Portability Analyzer an.

mfG Gü

Wow danke für die ausführliche Erklärung @gfoidl.

Jetzt hab ich schon nen ziemlich guten Überblick!

Hallo, bei mir wäre noch eine andere Frage.
Seit Jahren erstelle ich WPF-Anwendungen mit .Net, vorzugsweise noch mit FW4.0.
Habe jetzt auch schon mal Anwendungen in NetCore geschrieben, um zu testen.
Kann ich aber rückwirkend eine NetCore-DLL mit neuer Anwendungsfunktionalität auch in ein .Net-Projekt einbinden (DLL) um dann die Methoden anzusprechen?
Habe das mal probiert, das einbinden geht, Klasse instanziieren auch, aber wenn ich die Applikation starte kommt die Meldung kommenzig Fehlermeldungen und in derFehlerausgabe heißt es der Namespace der NetCore-DLL kann nicht gefunden werden.

Heißt das das es für die Einbindung noch ein Trick gibt?

Hallo oehrle,

Heißt das das es für die Einbindung noch ein Trick gibt?

Es geht halt einfach nicht. .NET Core bzw. ab .NET 5 ohne Core ist neuer und wird von .NET Desktop (bis .NET 4) nicht unterstützt. Da kann man nichts machen.
.NET Standard wäre möglich um für .NET 4 zu entwickeln.
WPF geht aber seit .NET Core 3.1 auch.

mfG Gü

Danke, mal sehen was ich bei mir umstellen kann. Hatte hier shcon mal was hilfreiches gefunden ...

https://www.youtube.com/watch?v=qc2WFaMfdp8

Es sind zwei unterschiedliche Technologien, als ob Du Lego und Duplo zusammen stecken willst.
Der einzig offizielle Support zwischen den beiden Welten ist .NET Standard, dafür war es gedacht und hat auch seinen Zweck erfüllt.

Dein Video zeigt auch was anderes als Deine Frage.

Kann ich aber rückwirkend eine NetCore-DLL mit neuer Anwendungsfunktionalität auch in ein .Net-Projekt einbinden (DLL) um dann die Methoden anzusprechen?

In dem Video wird Multi Targeting gezeigt, kein Backward-Referencing.

Das mit Lego und Duplo ist ein gutes Besipiel.

Was mache ich dann, wenn ich eine Applikation habe, die aus mehreren Projekten besteht, alles sind soweit noch mit FW4.0 erstellt. Man kann (können schon, aber die Zeit !) ja nicht alle Projekte umschreiben, auf .Net5/6 usw.
Mir ging es eigentlich darum, wenn ich neue Features programmiere, die bisher in der Anwendung noch nicht vorhanden waren, diese in .Net5/6 zu programmieren, aber rückwirkend in der Hauptapplikation aufgerufen / verwendet werden kann.
Welche Möglichkeiten hat man? Gibt es da keine Brücke, das neue im vorhadnenen (alten) zu verwenden?

Mit verwenden meine ich als Besipiel:

• Es wird eine neue Anforderung gebraucht, die es bisher noch nicht gab. Die Anforderung (eine Datenauswertung) wird in einem neuen Projekt (damit zukunfsfähing in .Net5) erstellt.

==> kann ich dieses Projekt irgendwie in meinem alten "Hauptprojekt" einbinden, damit ich es dort aufrufen kann und die Verarbeitung dort ausgeführt wird?

Man kann (können schon, aber die Zeit !) ja nicht alle Projekte umschreiben, auf .Net5/6 usw.

Sorry, aber "Zeit" ist eine faule Ausrede. Es geht hier schließlich um Dich, Deine Projekte, Deine Kunden und deren Zukunft.

• 2015, also vor SIEBEN JAHREN, war bekannt, dass .NET Core kommen wird.
• Seit 5 Jahren ist bekannt, dass NET FX ein Auslaufmodell ist.
• Seit 2016 gibt es .NET Standard 2.0, das eine breite API zwischen NETFX und NET Core hat.
• Seit 4 Jahren predigt Microsoft und die gesamte .NET Community: mach Dich bereit, dass Du migrieren MUSST.

Das MUSS jeder .NET Entwickler wissen. Es gibt keine Chance an diesen Infos vorbei zu gehen.
Spätestens wenn man mit Visual Studio täglich arbeitet, selbst mit alten Versionen.
Wer das ignoriert: selbst schuld.

Welche Möglichkeiten hat man?

Migrieren! Es wird Zeit! .NET Framework und .NET Standard haben keine Zukunft mehr!
Du musst alles auf .NET 5/6 heben - oder Du kommst aus der Welt nicht raus.
Da gibts absolut keinen anderen Weg.

Gibt es da keine Brücke, das neue im vorhadnenen (alten) zu verwenden?

Nochmal: Die Brücke heisst .NET Standard. .NET Basics seit 7 Jahren!
Diese Brücke war aber nur temporär, von .NET FX auf .NET Core 3 (bzw. ausgereiz auf 5).
Aber auch .NET Standard war allen bewusst, dass es nur für die Transition in die neue Welt gedacht ist.

Diese Brücke braucht man schon lang nicht mehr, wenn man sich entsprechend vorbereitet hat.
Daher wurde diese Brücke mit dem Ende von .NET Standard 2.1 auch eingerissen bzw. nicht mehr weiter entwickelt, kann aber noch genutzt werden.
Siehe Probleme und Zukunft von .NET Standard

Ok, dann muss ich ran.
Dann muss ich auch damit leben das diese Appliaktion nicht mehr auf alten WINXP (wir haben noch Maschinen mit XP) nicht mehr unterstützt werden, da wird es dann keinen Ausweg geben.

Windows XP besitzt seit 2014(!) keinerlei offiziellen Support mehr. Selbst der Extended Support ($$$$) hat 2016(?) geendet.
Neue Programmiersprachen und Runtimes, die seitdem entstanden sind, unterstützen XP schon ewig nicht mehr oder haben XP nie offiziell unterstützt.
Man muss auch in der .NET Welt lernen, alte Zöpfe abzuschneiden.

Wenn Du Windows XP immer noch unterstützen musst (ich kenn sowas aus der Maschinenbau-Welt, leider - ich komm ja auch da her)... dann musst Du für immer und ewig bei .NET Framework bleiben und darfst halt nichts mehr Neues nutzen und Dich damit abfinden.
Aber die Erwartung zu haben, dass neue Technologien und Runtimes auf Steinzeit-OS laufen: no way.

Genau richtig, Maschinensteuerungen, die kauft man und da bleiben die stehen.
Aber: Du hast es korrekt gesagt. Wo es möglich ist, muss der "alte Scheiß raus".
Danke.

Ich weiß nicht, wie die .NET 4.6.1-Unterstützung auf XP aussieht, aber 4.6.1 unterstützt .NET Standard 2.0
Dann kannst Du die Legacy-Lösung mit .NET Framework >4.6.1 anbieten und für den Rest .NET 6, alle Gemeinsamkeiten sind mit .NET Standard 2.0 umgesetzt.
Für aufwändigeren Code, der nicht so einfach in .NET Standard 2.0 geht, kannst Du mit bedingter Kompilierung arbeiten - das ist umständlich aber möglich.
Einige Frameworks machen das auch so (oder haben es so gemacht): Eine Code-Basis (z.B. als Shared Project) und dann diverse Bedingungen, welcher Code kompiliert werden soll und welcher nicht. Für .NET 4.6.1 und 6 gibt's dann zwei verschiedene Projekte, die das einbinden und die Bedingungen einstellen.

Das wäre wohl der aufwändigste Weg, aber so kannst Du in beiden Welten tanzen.

Ab April verlieren die .NET Framework Versionen 4.5.2, 4.6 und 4.6.1 den Support.
Hier sollte ein Umstieg auf eine Version ≥ 4.6.2 gemacht werden, falls diese noch zum Einsatz kommen.
Vermutlich wäre der direkte Sprung nach 4.8 am sinnvollsten.

Link:
.NET Framework 4.5.2, 4.6, 4.6.1 will reach End of Support on April 26, 2022

Wenn der TE aber auf Windows XP Support setzt, dann dürfte alles > 4.0 nicht mal supportet werden.
Und .NET 4.0 ist eigentlich schon lange EoL.

.NET Framework system requirements - .NET Framework

T-Virus

Hier sollte ein Umstieg auf eine Version ≥ 4.6.2 gemacht werden, falls diese noch zum Einsatz kommen.
Vermutlich wäre der direkte Sprung nach 4.8 am sinnvollsten.

Das sowieso ^^
Aber wenn es hier um XP geht, hat der TE wohl keine Wahl.

Wenn der TE aber auf Windows XP Support setzt, dann dürfte alles > 4.0 nicht mal supportet werden.

In dem Fall fliegt dann .NET Standard wohl ganz raus, Version 1.0 braucht min. .NET 4.5
Die Tabelle dazu: .NET-Standard

Dann bleiben nur noch Shared Projects und bedingte Kompilierung.
Vieles der beiden Frameworks sind - auf die Namen und den Code bezogen - ja gleich, wie gut/einfach das funktioniert, hängt dann davon ab, wie viele spezifische Funktionen genutzt werden.

Im Endeffekt ist eine Lösung ein Prozess pro Framework. So wie man auch 32bit DLLs in 64Bit Anwendungen benutzen kann.

Das ist natürlich mit deutlich mehr Aufwand verbunden. Aber wenn es wichtig ist, nimmt man den Aufwand auf sich.

Das ist zumindest für mich der Weg nach vorne um die Anwendung auf .NET 6 zu bringen. 3 Prozesse: .NET, .NET Framework 64bit und .NET Framework 32bit.

Wird halt nur nicht so einfach funktionieren, wenn es keinen richtigen Support für .NET 5/6 für XP gibt.
Da es keinen support gibt, wäre diese "Lösung" auch keine richtige Lösung sondern nur eine Krücke die vielleicht gut geht.
Aber gerade wenn man neue Features, die wiederum neue Technik benötigt, umsetzen will wird hier nicht weit kommen.

Wenn möglich sollte man sich von solchen toten Systemen verabscheiden, sobald es geht.
Alles andere ist tote Pferde in den Sonnenuntergang reiten.

T-Virus