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

[SOLVED] - dotnet publish - unterschiedliche Ergebnisse unter Linux ./. Windows
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

Themenstarter:

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

beantworten | zitieren | melden

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

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 .
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.820
Herkunft: Waidring

beantworten | zitieren | melden

Hallo LaTino,

gibt es diese Unterschiede auch wenn nur

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ü

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
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

Themenstarter:

beantworten | zitieren | melden

Enschuldige, dass ich erst jetzt antworte.
Zitat von gfoidl

gibt es diese Unterschiede auch wenn nur

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
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.832

beantworten | zitieren | melden

Ich geh mal davon aus, dass das Dein Stackoverflow Thread ist:
dotnet publish results include different set of libraries when run in linux/windows
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

Themenstarter:

beantworten | zitieren | melden

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

LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

Themenstarter:

beantworten | zitieren | melden

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:

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
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

Themenstarter:

beantworten | zitieren | melden

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
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers