Will Aspose.Cells support .NET 6 on Linux? System.Drawing.Common is no longer supported on non-Windows systems (because libgdiplus is of poor quality). See this official MS documentation page about this breaking change.
I know Aspose.Cells has a dependency on System.Drawing.Common in some cases as I’m getting the following error with the latest version (v21.12.0) in production.
System.TypeInitializationException: The type initializer for '\u0006 ' threw an exception.
---> System.TypeInitializationException: The type initializer for 'Gdip' threw an exception.
---> System.PlatformNotSupportedException: System.Drawing.Common is not supported on non-Windows platforms. See https://aka.ms/systemdrawingnonwindows for more information.
at System.Drawing.LibraryResolver.EnsureRegistered()
at System.Drawing.SafeNativeMethods.Gdip..cctor()
--- End of inner exception stack trace ---
at System.Drawing.SafeNativeMethods.Gdip.GdipStringFormatGetGenericTypographic(IntPtr& format)
at System.Drawing.StringFormat.get_GenericTypographic()
at \u0006 ..cctor()
--- End of inner exception stack trace ---
at \u0008 .\u0002(String \u0002, Font \u0003, Double \u0005)
at \u000F .\u0002(Int32 \u0002, Int32 \u0003, Int32 \u0005, Int32 \u0008, AutoFitterOptions \u0006)
at \u000F .\u0002(Cells \u0002, Int32 \u0003, Int32 \u0005, Int32 \u0008, Int32 \u0006, AutoFitterOptions \u000E)
at Aspose.Cells.Worksheet.AutoFitColumns()
I don’t exactly know when that dependency comes into play. But even so, I tried activating the temporary legacy support in the runtimeconfig.json file as explained in the doc and the error I now get is:
System.TypeLoadException: Cannot load type '\u0006 , Aspose.Cells, Version=21.12.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56'.
at Aspose.Cells.Workbook.Save(Stream stream, SaveOptions saveOptions)
at Aspose.Cells.Workbook.Save(Stream stream, SaveFormat saveFormat)
Here’s a reproduction of the later problem: CellsDotnet6.zip (2.2 KB)
It uses a Docker Alpine Linux image base to run a simple Aspose.Cells program.
Hi @dstj
I made some tests, when I tried to use the Alpine Mirror, "RUN apk update " fails may be due to network issues.
However, I write a project, use the SDK:6.0 mirror to run your code and get the correct results.
Please check my test project. DockerTest60_1217.zip (8.6 KB)
I compared two dockerfiles, I installed more package:libgdiplus, libx11-dev, please try to join the package to your dockerfile, can it solve this problem?
I think the Alpine had a smaller mirror and might be missing some of the necessary packages.
Alpine Linux is definitely smaller than Ubuntu for example. It is useful for server images where you don’t want extra, useless libraries.
libx11-dev is the “X11 client-side library (development headers)”. This really should not be necessary on a production server that has no GUI. But I tried it nonetheless, no change. issue still happens with .NET 6.
I ran another test with the same code, on both .NET 5 and .NET 6.
Results:
.NET 5 working
.NET 6 NOT working
The only differences is the targeted framework in the .csproj and the Docker base image (dotnet/runtime:5.0-alpine vs dotnet/runtime:6.0-alpine)
Hi @dstj
Please check this project, I make it from:
FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine AS base-runtime
However, this is a new project I created,
The installed packages and code are copied from yours.
under vs 2022, using Docker Desktop test pass, in data directory, there are my test generated files. DockerTest60_1220.zip (82.2 KB)
Your attached project does not work for me. The Dockerfile is invalid as you not reusing the same image aliases in your subsequent build steps (base-runtime vs base and build-dotnet vs build).
FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine AS base-runtime
...
FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build-dotnet
...
FROM build AS publish
...
FROM base AS final
Neither build nor base is previously defined, so Docker tries to use pull the docker.io/library/build:latest image.
The resulting error I get is:
$ docker build -t testingAsposeCells .
[+] Building 11.4s (6/6) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.08kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> CANCELED [internal] load metadata for docker.io/library/base:latest 11.3s
=> ERROR [internal] load metadata for docker.io/library/build:latest 10.8s
=> [auth] library/build:pull token for registry-1.docker.io 0.0s
=> [auth] library/base:pull token for registry-1.docker.io 0.0s
------
> [internal] load metadata for docker.io/library/build:latest:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: pull access denied, repository
does not exist or may require authorization: server message: insufficient_scope: authorization failed
But, the fact that you say
under vs 2022, using Docker Desktop test pass, in data directory, there are my test generated files.
leads me to believe that you are not executing the test in a Docker container as you should not see a file generated on your machine, the files should be generated in the Docker container itself.
Can you see show the Docker commands you run to confirm that is works? Thanks.
We’re making some progress, the issue only seems to happen when the dotnet publish options -p:PublishReadyToRun=true -p:PublishReadyToRunShowWarnings=true are used.
R2R binaries improve startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. The binaries contain similar native code compared to what the JIT would produce. However, R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios, and the native version of the same code. R2R is only available when you publish an app that targets specific runtime environments (RID) such as Linux x64 or Windows x64.
Working:
RUN dotnet publish --configuration Release --runtime linux-musl-x64 --self-contained=true --output /app/publish
Testing Aspose.Cells under .NET 6 & Linux
Unhandled exception. System.TypeLoadException: Cannot load type '♠ , Aspose.Cells, Version=21.12.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56'.
at Aspose.Cells.Workbook.Save(String fileName, SaveOptions saveOptions)
at Aspose.Cells.Workbook.Save(String fileName)
at CellsDotnet6.Program.Main(String[] arg) in /src/Program.cs:line 60
I tried without Docker, building simply on Linux: same problem with the p:PublishReadyToRun options.
The Aspose.Cells.dll in the working version is 13,911,312 bytes, whereas in the non-working PublishReadyToRun one, the Aspose.Cells.dll is 42,178,560 bytes (which is to be expected). But it should not cause it to fail.
The System.Drawing.Common file is also different (working: 372,840 bytes vs non-working 857,600 bytes).
Hi @dstj
Thank you for sharing, I did some further research through “PublishReadyToRun” and found that the problem can be reproduced under windows. I share my project for reproducing the problem TestPublishReadyToRun.zip (19.9 KB)
.
I can reproduce this problem by executing the following command from the Windows Command Line.
Please try, I think, this may be the problem you met.
cd …\TestPublishReadyToRun\TestPublishReadyToRun
dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true
cd bin\Release\net6.0\win-x64\publish
TestPublishReadyToRun.exe
1, This problem should have occurred after we Obfuscate the DLL(A necessary step before releasing the Aspose Cells DLL), because I used a DLL that was not Obfuscated and did the above steps to generate files properly. We need more time to study it.
2, I think this problem should have nothing to do with the Graphics Library. Through Microsoft’s documentation and our testing, system.drawing.common can run in Net 6.
We understand your concerns, and are working on the Graphics Library Implementation, dropping the system.drawing.common under Linux, and supporting it before the NET7 implementation.
Hi @leoluo - We’re experiencing the same issue with Aspose.Cells on .NET 6 on Windows. Is there any way we can see the status of the issue that you mention here ( CELLSNETCORE-322), or could you share the current status and if there are any workarounds, apart from disabling R2R?
We are pleased to inform you that the issue has been resolved. The fix will be included in our upcoming release (Aspose.Cells for .NET v22.2) which is scheduled to be published in the next few days (either before the end of this week or in the next week or so).
Hi,
We see now that this is actually an issue with Aspose.Words and Aspose.Slides as well. Exactly the same symptom as for Aspose.Cells – when publishing with ready to run, we get this error:
Cannot load type '♣ , Aspose.Words, Version=22.2.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56'.
at ☻ .♣ (Int32 ☻, ♣ ♥, Boolean& ♣, Boolean)
at ☻ . (Int32 ☻, Boolean ♥)
at ☻ .♣ (Int32 ☻, ♣ ♥)
at ☻ .☻ (Int32 ☻)
at ☻ . (☻ ☻, ♥)
at ☻ .☻ ()
at ☻ . (Boolean ☻)
at ☻ (Object ☻)
at ☻ ? (Object ☻)
at ☻ . ()
at ☻ .☻ (Object ☻, UInt32 ♥)
at ☻ . (Boolean ☻)
at ☻ . (Object[] ☻, Type[] ♥, Type[] ♣, Object[])
at Aspose.Words.License..ctor_2()
at Aspose.Words.License..ctor()
Here’s the publish command we run (on Windows):
dotnet publish -r win-x64 -p:PublishReadyToRun=true -c Debug --no-self-contained .\Foobar.csproj
If we exclude these assemlies from ready to run in the project file:
Will I need to create a new ticket for this? Or is this fixed in the next version for Aspose.Words/Slides, together with the fix for Aspose.Cells that you have confirmed is on its way already?
We use the latest version of the assemblies, on .NET6.
Cells: 22.1
Words: 22.2
Slides: 22.1