ich arbeite aktuell daran, unsere Anwendung auf die Cross Platform-Version (31.0.0) von List & Label umzustellen. Unsere Anwendung ist eine ASP.NET 8 Webanwendung und soll künftig in einer dockerisierten Linux-Betriebssystemumgebung deployed werden.
Der Export von List and Label ist konfiguriert einen MemoryStream zu erzeugen.
Um diesen MemoryStream zu erzeugen müssen (soweit mir bekannt) temporäre (PDF) Dateien im Dateisystem erstellt werden.
Dies schlägt soweit ich das beurteilen kann fehl, da diese nirgends im Docker-Container erstellt werden bzw. der MemoryStream leer ist. Es wird auch keine Fehlermeldung ausgegeben.
Es können auch keine Logdateien erstellt werden.
Daher habe ich ein paar Fragen:
Unter welchem Pfad werden standardmäßig die temporären Exportdateien unter Linux abgelegt?
Unter Windows werden diese anscheinend unter C:\Windows\Temp\combit erstellt.
Leider konnte ich dazu in der Dokumentation von List & Label Cross Platform keine Angaben finden.
Ist es möglich, den Speicherpfad für die temporären Exportdateien zu ändern?
Die Angabe der Exportpfades bei als Export Option hat auch nicht dazu geführt das die temporären Dateien erstellt werden.
Ist es möglicherweise nötig einen bestimmten Benutzer mit speziellen Zugriffsrechten auf bestimmte Ordner anzulegen?
Ich habe testweise mit dem Root Benutzer ausprobiert (natürlich nur zur Testzwecken), aber das hat auch nicht geholfen.
List & Label Cross Platform benötigt keine temporären Dateien und kann direkt im Speicher einen Export durchführen. Daher würde ich Zugriffsrechte eher ausschließen. Wie genau sieht deine Docker-Konfiguration aus? Es werden einige Linux-Bibliotheken benötigt, s. hier:
Vielen Dank für die schnelle Antwort und die Aufklärung bezüglich den temporären Dateien.
Natürlich stelle ich gerne meine Dockerfile (dockerfile.txt (1.0 KB)) zur Analyse des Problems zur Verfügung. Ich musste allerdings die Datei in eine Textdatei umändern damit ich diese hochladen konnte und ein paar Links bzw. interne Namen in der Datei austauschen.
Bezüglich SkiaSharp hatte ich im Vorfeld auch bereits ein paar Probleme:
Es wurde die falsche Version verwendet (88.1 anstelle von 3.119.0).
Dies konnte ich aber lösen indem ich in der App.csproj Paket Referenzen auf SkiaSharp hinzugefügt habe.
Ich konnte nun das Problem mit dem leeren MemoryStream bereits auf dem Rechner eines Kollegen nachstellen, indem ich auf seinem Rechner gedebuggt habe.
Es kam keine Fehler, aber der Memory Stream war komplett leer (Länge 0).
Das “… NoDependencies” - Package sollte nicht referenziert werden. Wenn es dennoch nicht klappen sollte würde ich vorschlagen, dass du im Supportportal einen Case eröffnest, dann können wir uns das einmal zusammen anschauen. Die Lösung können wir dann hier posten.
Ich habe das “SkiaSharp.NativeAssets.Linux.NoDependencies“ Package entfernt.
Das Problem, dass der MemoryStream unter macOS und Linux beim Export leer bleibt besteht allerdings weiterhin.
Ich werde hierfür ein Support Ticket erstellen.
Ich konnte das Problem nun selbst beheben.
Der Grund warum der Export fehlschlug war, dass das falsche Pfad Trennzeichen für den Dateipfad der Projektdateien (.lst usw.) verwendet wurde.
Nachdem ich das behoben habe, funktioniert der Export nun.
Ah super - wir haben just gestern eine Verbesserung in dem Bereich vorgenommen:
06.11.2025 {Cross Platform} Relative paths were not correctly normalized to the OS-specific format on Linux and MacOS. (Requires combit.ListLabel31.CrossPlatform.dll 31.001)
Das Handling ist recht tricky, wir haben es wie unten gelöst und hoffen, damit ein “best of all worlds” gefunden zu haben. Die Herausforderung ist insbesondere bei Verwendung von ProjectPath$ und relativen Dateinamen z. B. für Projektbausteine. Daraus ergibt sich gerne ein Pfad mit Backslashes. Wenn sich aus deinem Problem noch eine Verbesserungsmöglichkeit ergeben würde sag gerne Bescheid. Auch der Umgang mit Streams ist inzwischen weiter verbessert worden.
/// <summary>
/// Normalizes the file name for use in file or repository operations.
/// If the file name starts with the repository item prefix, it is returned unchanged.
/// Otherwise, the file path is normalized to the current OS format and converted to an absolute path.
/// </summary>
/// <param name="fileName">The file name to normalize.</param>
/// <returns>
/// The normalized file name, either as a repository item ID or an absolute file path.
/// </returns>
public static string NormalizeFileName(string fileName)
{
if (fileName.StartsWith(LlConstants.RepositoryItemPrefix, StringComparison.OrdinalIgnoreCase))
{
return fileName;
}
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows) || File.Exists(fileName))
{
return Path.GetFullPath(fileName);
}
if (LooksLikeRelativeWindowsFileName(fileName))
{
fileName = fileName.Replace('\\', Path.DirectorySeparatorChar);
}
return Path.GetFullPath(fileName);
}
/// <summary>
/// Determines whether the specified path string appears to be a relative path in Windows format.
/// This is used as a heuristic to identify Windows-style paths on non-Windows platforms.
/// </summary>
/// <param name="fileName">The path string to evaluate.</param>
/// <returns>
/// <c>true</c> if the path looks like a relative Windows path; otherwise, <c>false</c>.
/// </returns>
private static bool LooksLikeRelativeWindowsFileName(string fileName)
{
if (string.IsNullOrEmpty(fileName))
{
return false;
}
fileName = fileName.TrimStart();
if (fileName.StartsWith(".\\") || fileName.StartsWith("..\\") || fileName.StartsWith('\\'))
{
return true;
}
return false;
}
