myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Entwicklungs- und Laufzeitumgebung (Infrastruktur) » [SOLVED] - dotnet publish - unterschiedliche Ergebnisse unter Linux ./. Windows
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

[SOLVED] - dotnet publish - unterschiedliche Ergebnisse unter Linux ./. Windows

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.999
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen


LaTino ist offline

[SOLVED] - dotnet publish - unterschiedliche Ergebnisse unter Linux ./. Windows

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hi,

ich bin heute über eine Merkwürdigkeit gestolpert, für die ich keine Erklärung habe. Wir haben GitLab im Einsatz, einige Runner unter Linux, einige unter Windows. Mir ist heute aufgefallen, dass die Ergebnisse des "dotnet publish" Befehls für dieselbe Target Runtime unterschiedliche Ergebnisse erzeugen.

Der publish-Aufruf

Code:
1:
dotnet publish ./PROJECTNAME/PROJECTNAME.csproj -c Release --runtime win-x64 --self-contained false

Das Ergebnis, das die Linux-Runner erzeugen, enthält drei Dateien, die die Windows-Runner nicht dazupacken:
- System.Collections.Immutable.dll
- System.ComponentModel.Annotations.dll
- System.Diagnostics.DiagnosticSource.dll

Ich war bisher davon ausgegangen, dass ich mich darauf verlassen kann, dass ein und derselbe Befehl in ein und derselben SDK-Version zu ein und demselben Ergebnis führt. Das jetzt verunsichert mich doch ziemlich.

Hat jemand eine Erklärung?

LaTino

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von LaTino am 10.06.2020 11:18.

Neuer Beitrag 29.05.2020 16:31 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.662
Entwicklungsumgebung: VS 2019
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo LaTino,

gibt es diese Unterschiede auch wenn nur

Code:
1:
dotnet publish ./PROJECTNAME/PROJECTNAME.csproj -c Release

verwendet wird?

Die Runtime hat natürlich Unterschiede zwischen den verschiedenen Betriebssystemen. Nur als Beispiel wird für Windows das Windows-API verwendet, während *nix auf die entsprechenden POSIX-APIs zugreift.

Durch die Angabe der Ziel-Runtime --runtime win-x64 wird entweder "cross compiled" od. nicht. Daher kann es -- auch beeinflusst von den NuGet-Referenzen -- zu Unterschieden der Build-Ausgabe kommen.

Konkret kann ich mangels Kenntnis des Projekts aber nicht auf die tatsächliche Ursache zurückschließen.

Zitat:
dass ein und derselbe Befehl in ein und derselben SDK-Version zu ein und demselben Ergebnis führt

Dem ist auch so -- bis auf den Unterschied dass ab .NET Core 3.0 bei Windows eine PROJECTNAME.exe erzeugt wird, während bei *nix eine PROJECTNAME erzeugt wird.

mfG Gü
Neuer Beitrag 29.05.2020 17:35 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.999
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Enschuldige, dass ich erst jetzt antworte.

Zitat von gfoidl:
gibt es diese Unterschiede auch wenn nur

Code:
1:
dotnet publish ./PROJECTNAME/PROJECTNAME.csproj -c Release

verwendet wird?

Ja. Exakt dieselben drei Dateien.

Der Punkt, den ich nicht nachvollziehen kann, ist dieser hier:

Zitat von gfoidl:
Durch die Angabe der Ziel-Runtime --runtime win-x64 wird entweder "cross compiled" od. nicht. Daher kann es -- auch beeinflusst von den NuGet-Referenzen -- zu Unterschieden der Build-Ausgabe kommen.

Mein zugegeben unvollständiges Verständnis des Vorgangs ist, dass eben gegen die entsprechenden Bibliotheken der Zielplattform kompiliert wird. Die drei unter Linux eingebundenen Bibliotheken werden auch nicht genutzt - sonst würde das unter Windows erzeugte Ergebnis, dass diese Bibliotheken nicht hat, ja gar nicht laufen.

Ich hätte das als reine Unschönheit abgetan, allerdings verursachen die verschiedenen Ergebnisse einen Schluckauf in unserer Gitlab-Pipeline, der langsam echt störend wird.

Grüße,

LaTino
Neuer Beitrag 08.06.2020 16:33 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 14.202
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ich geh mal davon aus, dass das Dein Stackoverflow Thread ist:
 dotnet publish results include different set of libraries when run in linux/windows
Neuer Beitrag 08.06.2020 17:47 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.999
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Nein. Allerdings ist es tatsächlich dasselbe (nicht nur das gleiche) Problem.

LaTino
Neuer Beitrag 08.06.2020 18:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.999
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

So, ich habe noch einmal etwas gebuddelt. Das Problem haben wir uns mit einer Abhängigkeit auf Microsoft.EntityFrameworkCore eingetreten. Das NuGet-Package listet die drei Abhängigkeiten auch auf - die Merkwürdigkeit ist also, dass die Bibliotheken unter Windows fehlen, und nicht, dass sie unter Linux auftauchen.

Interessanterweise:

Code:
1:
2:
3:
4:
5:
dotnet new console -o Example
cd Example
dotnet add package Microsoft.EntityFrameworkCore
dotnet publish ./Example.csproj -o ../publish -c Release 
ls ../publish

..führt dazu, dass die Bibliotheken auch unter Windows im Ausgabeverzeichnis liegen.

Es liegt also vermutlich am Projekt, wobei ihr mir nicht wirklich helfen könnt. Ich werde die Abhängigkeiten mal Stück für Stück entfernen / wieder einfügen und schauen, ob das einen Effekt hat. Sollte ich über die Lösung stolpern, melde ich mich wieder.

LaTino
Neuer Beitrag 09.06.2020 14:12 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4122.png


Dabei seit: 03.04.2006
Beiträge: 2.999
Entwicklungsumgebung: Rider / VS2019 / VS Code
Herkunft: Thüringen

Themenstarter Thema begonnen von LaTino

LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Update der Package Microsoft.EntityFrameworkCore von 3.1.1 auf 3.1.5 hat das Problem beseitigt. Ich habe in den Readmes keinerlei Hinweis auf eine Änderung diesbezüglich gefunden. Nicht die erste Änderung in net core 3.1, die unsere Build-Pipeline zerschießt. Ärgerlich, unnötig.

LaTino
Neuer Beitrag 10.06.2020 11:17 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 3 Monate.
Der letzte Beitrag ist älter als 3 Monate.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 26.09.2020 14:19