Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Jegliche .NET DLL in dotnet core verwendbar?
Christoph K.
myCSharp.de - Member

Avatar #avatar-3248.png


Dabei seit:
Beiträge: 815
Herkunft: Köln

Themenstarter:

Jegliche .NET DLL in dotnet core verwendbar?

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1.029
Herkunft: Mainz

beantworten | zitieren | melden

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".
private Nachricht | Beiträge des Benutzers
Christoph K.
myCSharp.de - Member

Avatar #avatar-3248.png


Dabei seit:
Beiträge: 815
Herkunft: Köln

Themenstarter:

beantworten | zitieren | melden

Vielen Dank für deine schnelle Antwort.

Was ist denn jetzt schon wieder dotnet Standard ? :-D

Das ist komplett an mir vorbei gegangen.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.288

beantworten | zitieren | melden

.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.
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.860
Herkunft: Waidring

beantworten | zitieren | melden

Hallo Christoph K.,
Zitat
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.
Zitat
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).
Zitat
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.
Zitat
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.
Zitat
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.
Zitat
weil wir eine Migration überlegen.
Schau dir dabei auch The .NET Portability Analyzer an.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Christoph K.
myCSharp.de - Member

Avatar #avatar-3248.png


Dabei seit:
Beiträge: 815
Herkunft: Köln

Themenstarter:

beantworten | zitieren | melden

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

Jetzt hab ich schon nen ziemlich guten Überblick!
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 437
Herkunft: Germany

Nachfrage NetCore in .Net

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.860
Herkunft: Waidring

beantworten | zitieren | melden

Hallo oehrle,
Zitat
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ü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 437
Herkunft: Germany

beantworten | zitieren | melden

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

https://www.youtube.com/watch?v=qc2WFaMfdp8
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von oehrle am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.288

beantworten | zitieren | melden

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.
Zitat
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.
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 437
Herkunft: Germany

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.288

beantworten | zitieren | melden

Zitat von oehrle
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.
Zitat von oehrle
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.
Zitat von oehrle
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
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 437
Herkunft: Germany

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16.288

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
oehrle
myCSharp.de - Member



Dabei seit:
Beiträge: 437
Herkunft: Germany

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Experte

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.876
Herkunft: Düsseldorf

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Experte



Dabei seit:
Beiträge: 2.083
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Experte

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.876
Herkunft: Düsseldorf

beantworten | zitieren | melden

Zitat
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.

Zitat
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.
private Nachricht | Beiträge des Benutzers
Jompikumpi
myCSharp.de - Member



Dabei seit:
Beiträge: 60

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Experte



Dabei seit:
Beiträge: 2.083
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers