Laden...

Ich habe noch immer mit den .NET Core Nachfolgern Probleme

Erstellt von theuserbl vor einem Jahr Letzter Beitrag vor einem Jahr 1.357 Views
T
theuserbl Themenstarter:in
3 Beiträge seit 2010
vor einem Jahr
Ich habe noch immer mit den .NET Core Nachfolgern Probleme

Also ich habe noch immer mit den .NET Core Nachfolgern Probleme.

Ganz aktuell z.B. das .NET 7.0.0-preview7 SDK von
Download .NET 7.0 (Linux, macOS, and Windows)
runtergeladen.
Da ich es nicht installieren möchte, lade ich für Windows eine zip-Datei runter.

Erste Überraschung dieses SDKs:
Es gibt im Hauptverzeichnis nur ein dotnet.exe .
Kein csc.exe und kein vbc.exe .
Auch in den Unterverzeichnisssen finde ich keine Compiler.
Also da bin ich von Java anderes gewohnt. Da sind alle Executables in der zip-Datei vorhanden.

Aber ich hatte mit dem .NET Framework auf Windows ein kleines Hallo-Welt Programm geschrieben gehabt und zu Hallo.exe kompiliert. MIt dem .NET Framework läuft es auch super.

Und was liefert ein ".\dotnet.exe .\Hallo.exe" ?


A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'D:\dotnet7\'.
Failed to run as a self-contained app.
  - The application was run as a self-contained app because 'D:\dotnet7\Hallo.runtimeconfig.json' was not found.
  - If this should be a framework-dependent app, add the 'D:\dotnet7\Hallo.runtimeconfig.json' file and specify the appropriate framework.

WTF??? Geht es noch komplizierter?

Ok, ich habe nun also aus dem Unterverzeichnis .\shared\Microsoft.NETCore.App die Datei hostpolicy.dll ins Hauptverzeichnis kopiert.

Danach starte ich mit dotnet.exe mein Hallo.exe erneut.
Nun kommt die Meldung


Could not resolve CoreCLR path. For more details, enable tracing by setting COREHOST_TRACE environment variable to 1

Was ist das für ein Mist?

Im Gegensatz zum .NET Framework, kann ich das neue .NET nicht nutzen.

Und das bezieht sich nur auf das neuere .NET selber.

Mit der auf dem .NET Core aufbauenden PowerShell unter
https://github.com/PowerShell/PowerShell/releases
habe ich keine Probleme.
Dort einfach die zip-Datei entpacken und im Hauptverzeichnis pwsh.exe starten.
Sie funktioniert unter Windows und Linux.

Aber auch dort hätte ich gerne gewusst, auf welcher .NET Version genau die Powershell aufsetzt.

$PSVersionTable sagt dazu nichts genaues.
Da wäre so eine Ausgabe wie "7.0.0-preview7" schön.
Es gibt dort zwar die Ausgabe "7.3.0-preview.6", aber das bezeiht sich auf die Powershell-Version und nicht auf die drunterliegende .NET Version.

Gibt es irgendwo eine Dokumentation mit den ersten Schritten in .NET Core / .NET > 4 ?
Muß man nun für jede exe-Datei zusätzlich eine json-Datei erstellen?
Beim .NET Framework war es nicht nötig.

Grüße
theuserbl

M
368 Beiträge seit 2006
vor einem Jahr

Grundsätzlich funktionieren das Herunterladen und Entpacken der zip-Datei, sowie das Anlegen und Starten einer Konsolenapplikation: .NET Tutorial | Hello World in 5 minutes (s.a. Screenshot im Anhang)

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

T
2.219 Beiträge seit 2008
vor einem Jahr

.NET und Java sind auch zwei Paar Schuhe, du solltest dich nochmal mit dem neuen .NET beschäftigt.
.NET Framework ist die alte Welt, die ist auf dem Weg des EoL in den nächsten Jahren.
Darauf sollte man keine neuen Projekte mehr aufbauen.
Alte Projekte sollte man nach .NET 5+ portieren.

Anbei solltest du die Preview dann auch nicht nutzen.
Da der Name schon sagt, dass es sich dabei nicht um eine fertige Version sondern nur eine Vorschau handelt, solltest du eher auf die aktuelle Stable Version .NET 6 gehen.
Dies lässt sich auch z.B. via winget einfach installieren.

So wie sich dein Post liest fehlen die dir Grundlagen der neuen .NET Welt komplett.
Die alten Ansätze sind eben mit dem Framework obsolete bzw. gibt es nur noch Übergangslösungen.
Aber auch diese Ansätze sollte man wenn möglich meiden und den aktuellen Way to Go verwenden!

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.

L
11 Beiträge seit 2019
vor einem Jahr

Hallo theuserbl

du schreibst, dass du die .NET Framework Anwendung nicht mit dem neuen .NET ausführen konntest:

Aber ich hatte mit dem .NET Framework auf Windows ein kleines Hallo-Welt Programm geschrieben gehabt und zu Hallo.exe kompiliert. MIt dem .NET Framework läuft es auch super.

Und was liefert ein ".\dotnet.exe .\Hallo.exe" ?

  
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'D:\dotnet7\'.  
Failed to run as a self-contained app.  
  - The application was run as a self-contained app because 'D:\dotnet7\Hallo.runtimeconfig.json' was not found.  
  - If this should be a framework-dependent app, add the 'D:\dotnet7\Hallo.runtimeconfig.json' file and specify the appropriate framework.  
  

Das ist auch das erwartete Verhalten. .NET Framework und .NET sind zwei unterschiedliche Laufzeitumgebungen und (abgesehen von ein paar Brücken dazwischen, zum Beispiel .NET Standard) nicht kompatibel. Wenn du also Anwendungen mit der dotnet.exe, die du heruntergeladen hast, ausführen willst, dann müssen diese auch entsprechend für .NET kompiliert worden sein.

Eine beispielhafte Anleitung, wie du .NET Anwendungen entwickeln kannst, hat M.L. dir bereits verlinkt. Dafür brauchst du auch nicht die csc.exe, die du in der zip-Datei vermisst hast, da es inzwischen auch eine neue Compiler-Plattform für .NET gibt. Mehr Informationen zu den Unterschieden von .NET Framework und .NET findet du auch unter [FAQ] Das .NET Ökosystem - .NET, .NET Core, .NET Standard, NuGet und Co.

Viele Grüße
Lukas

2.078 Beiträge seit 2012
vor einem Jahr

Nochmal wegen der Vollständigkeit: .NET CLI
Da hast Du dann auch den Compiler - die dotnet.exe macht das alles.

Für mich sieht das so aus, als hättest Du auf gut Glück dotnet heruntergeladen und einfach mal ausprobiert.
Das geht - wie Du ja selber merkst - nicht gut aus, Du solltest dich vorher zumindest in die Grundlagen einarbeiten, Microsoft bietet genug Artikel dazu.

6.911 Beiträge seit 2009
vor einem Jahr

Hallo,

Da ich es nicht installieren möchte, lade ich für Windows eine zip-Datei runter.

Der Installer wird ja gerade destwegen angeboten, damit die Pfade, etc. nicht manuell gesetzt werden müssen.
Mit dem zip (ala xcopy-Deploy) kann eine bestehende Installation überschrieben werden od. man erfüllt die nötigen Vor- und Nachschritte selbst. Das ist so aber auch dokumentiert -- siehe Download and manually install.

Bitte immer Dokus lesen bevor die Schuld auf eine Technologie geschoben wird!

Kein csc.exe und kein vbc.exe .
Auch in den Unterverzeichnisssen finde ich keine Compiler.

In .NET ist seit jeher die Assembly das Binär-Produkt. Beim .NET Framework wurde eine EXE erzeugt, die im Grunde nichts anderes als der Code gepackt als DLL und zusätzlich der Loader-Teil für das Betriebssystem ist. Damit das OS das auch verwenden kann wurde es als nur als EXE "verpackt".

In .NET Core und später .NET wurde nur eine DLL erzeugt*, welche mittels dotnet MeineAnwendung.dll gestartet werden kann. dotnet ist dabei der Host und enthält u.a. den Loader-Teil fürs OS.

Im Ordner .\dotnet-sdk-7.0.100-preview.7.22377.5-win-x64.zip\sdk\7.0.100-preview.7.22377.5\Roslyn\bincore sind nun die Compiler tatsächlich vorhanden 😉
Aber nicht als EXE, sondern als csc.dll (C# Compiler) und vbc.dll (VB.NET Compiler).
Wie vorhin erwähnt, können diese via dotnet csc.dll ausgeführt werden. I.d.R. jedoch via MsBuild-Task der die Assembly lädt und direkt ausführt**.

* bei einem Framework-dependent deployment, es gibt auch weitere Möglichkeiten bei denen eine EXE direkt erstellt wird, aber das lässt sich in der Doku nachlesen

** ein wenig kompliziertes ist es mittlerweile schon, da zur Leistungssteigerung und für den Gebrauch in VS eine Art Build-Server gestartet wird, der den / die Compiler-Instanzen verwaltet

WTF??? Geht es noch komplizierter?

Ok, ich habe nun also aus dem Unterverzeichnis .\shared\Microsoft.NETCore.App die Datei hostpolicy.dll ins Hauptverzeichnis kopiert.

Obs noch komplizierter geht weiß ich nicht, aber du bist schon ganz gut dabei 😉

Mit einem Blick in die Doku (siehe oben) od. durch Verwendung des Installers hättest du weniger Frust und die Zeit, welche für deinen Beitrag hier benötigt wurde, hätte in Produktives umgesetzt werden können.

Muß man nun für jede exe-Datei zusätzlich eine json-Datei erstellen?
Beim .NET Framework war es nicht nötig.

Nein. Zum Einen geschieht dies automatisch durch die Build-Tools, zum Anderen werden diese json-Dateien bei Single-File-Deployment ebenfalls in die EXE gepackt.
.NET Framework funktioniert z.T. anders und v.a. nicht auf anderen OS als Windows. Daher sind auch andere Konzepte nötig um wirklich plattformunabhängig sein zu können.

Betrachte diese json-Dateien einfach als Teil der Build-Ausgabe. Diese stören doch nicht? Falls es es dich stört und du nur eine EXE als Ausgabe haben willst, so schau dir Single-file deployment and executable 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!"

T
theuserbl Themenstarter:in
3 Beiträge seit 2010
vor einem Jahr

Danke an alle.

Ja, es hat nun funktioniert. 🙂

Zuvor hatte ich mich nicht weiter damit auseinandergesetzt, weil ich dachte: "Oh, funktioniert noch nicht so gut. Wird Microsoft sicher in Zukunft beheben, so dass es benutzerfreundlicher wird. Also warte ich erst einmal ab..."
Aber es blieb immer so.

Das neue .NET hat mich nun doch sehr überrascht.

So ist ja das Anfangs C#-Programm eins, das eher wie aus einer Skriptsprache aussieht: Ohne Main-Methode und Klasse direkt mit dem Befehl losgelegt.

Desweiteren verwundert WIE mit dem .NET gearbeitet wird. Das fühlt sich an wie Visual Studio - nur ohne GUI:

  • Man wählt den Projektordner aus, wo die Projektdateien landen.
  • Im Projekt-Order wird eine Visual Studio Projektdatei (MyApp.csproj) angelegt.
  • Die Binaries entstehen nicht standardmäßig wie beim alten .NET FRamework, C/C++ und Java an der Stelle, wo auch der Quellcode ist, sondern es werdem - wie bei VisualStudio - Unterordner "bin" und "obj" erstellt, die ihrerseits jeweils entweder einen Unterordner "Debug" oder "Release" haben, wo dann die Binärdateien enthalten sind.

Grüße
theuserbl

T
2.219 Beiträge seit 2008
vor einem Jahr

Kleine Info:
Die Verkürzung der Haupt CS Datei ist nur Syntax Zucker.
Im Hintergrund wird die Klasse samt Main Methode generiert.
Ohne funktioniert es bei .NET eben nicht.

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.

6.911 Beiträge seit 2009
vor einem Jahr

Hallo theuserbl,

Das fühlt sich an wie Visual Studio - nur ohne GUI:

😉
VS verwendet (mehr od. weniger) die gleichen Build-Tools, daher ist deine Aussage schon korrekt.

  • Im Projekt-Order wird eine Visual Studio Projektdatei (MyApp.csproj) angelegt.
  • Die Binaries entstehen nicht standardmäßig wie beim alten .NET FRamework, C/C++ und Java an der Stelle, wo auch der Quellcode ist, sondern es werdem - wie bei VisualStudio - Unterordner "bin" und "obj" erstellt, die ihrerseits jeweils entweder einen Unterordner "Debug" oder "Release" haben, wo dann die Binärdateien enthalten sind.

Dass das Kompilat im gleichen Ordner landet wie die Quell-Dateien ist ein Anti-Pattern und sollte ohnehin vermieden werden.
Die Unterscheidung zwischen Debug / Release macht auch Sinn, da es dem Compiler frei steht für Release mehr Optimierungen durchzuführen.

Gängige Build-Tools anderer Sprachen / Plattformen wie z.B. CMake (hauptsächlich für C/C++) verhalten sich hier nicht anders. Statt der csproj gibt es eine / mehrere CMakeList.txt und die Ausgabe erfolgt auch in einem von der Quelle unterschiedlichen Pfad.

MsBuild (das Tool welches die csproj verarbeitet) muss du ja nicht verwenden, sondern kannst auch direkt mit CSC arbeiten. Aber ohne Build-Script (welches csproj letztlich auch ist) wird es eher schnell unhandlich.
Mit und ohne csproj kann der Ausgabe-Pfad auch konfiguriert werden -- standardmäßig werden halt Defaults verwendet, die sich in .NET so eingebürgert haben.

So ist ja das Anfangs C#-Programm eins, das eher wie aus einer Skriptsprache aussieht: Ohne Main-Methode und Klasse direkt mit dem Befehl losgelegt.

Zumindest in der VS-Projektvorlage kann die "alte Verhalten" mit class Program und static void Main wiederhergestellt werden.
Aber ich finds ohne netter, denn wozu immer wieder den unnötigen Code (generieren lassen). Der bläht ja nur auf ohne wirklichen nutzen.

Dass es aussieht wie eine Skriptsprache war in der Tat eine der Motivationen hinter dieser Änderung, denn für Einsteiger wurde es als unnötige Hürde erachtet eine Klasse und eine statische Methode zu erstellen, welche als Einstieg (ins Programm) dienen.
Wie T-Virus erwähnt ist das aber nur Compiler-Magick

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!"

M
368 Beiträge seit 2006
vor einem Jahr

Skriptsprache ... direkt mit dem Befehl losgelegt.

Bei einer Skriptsprache hat man idR weniger Formalien einzuhalten bis zum Programm, verzichtet aber auch auf Sicherheiten und andere Aktivitäten im Hintergrund. Z.B. Datentypgarantie oder das nur die geänderten Teile eines Programms interpretiert (eher: kompiliert) werden. Aber auch hier gibt es Entwicklungen, siehe youtube, MouseVsPython, "Python 101 - Type Hinting in Python"

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉