Laden...

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

Erstellt von LaTino vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.366 Views
LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 3 Jahren
[SOLVED] - dotnet publish - unterschiedliche Ergebnisse unter Linux ./. Windows

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

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

6.911 Beiträge seit 2009
vor 3 Jahren

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.

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

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 3 Jahren

Enschuldige, dass ich erst jetzt antworte.

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:

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)

16.807 Beiträge seit 2008
vor 3 Jahren

Ich geh mal davon aus, dass das Dein Stackoverflow Thread ist:
dotnet publish results include different set of libraries when run in linux/windows

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 3 Jahren

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)

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 3 Jahren

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)

LaTino Themenstarter:in
3.003 Beiträge seit 2006
vor 3 Jahren

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)