we just need it done not screenshots begging for  forgivness.

this stopped me buying your blazor components cause i cant trust your company will keep current  

 

We are creating infrastructure just for running Telerik reporting in .NET 6 / Debian outside of our primary web application running containerized on .NET 7.

 

This entire situation has left a terrible taste in my mouth - you guys knew and should have been prepared for this. We will be considering slowly moving to ActiveReports when our new application goes live. We shouldn't have to search for a glorified blog post -- this should have been front and center within the release notes.

Thank you, Ivan.

 

We've been a Telerik customer for years, and we've been waiting for this fix for a very long time. This is seriously damaging our products since we cannot implement newer, better versions of .NET because of this problem. Our hearts will be broken if this doesn't come out in R3 this year.

Fingers crossed, I hope the best for your team so they can finally implement this and be ready for .NET 8.

I just wanted to check in and see what the status of this is moving towards 20203.R3.  Are we on schedule for linux support in 2023.R3?  Below is what we were told would be in place for 2023.R2:

"For R2 we will implement an abstraction of the graphics layer to a set of interfaces, but the engine still will be using the GDI+ implementation. This abstraction is mandatory so we can plug the Skia implementation and use it instead of the GDI+ calls."

This needs to be fixed as soon as possible. The Telerik.Reporting for ASP.NET Core worked until version 7.0.5. When updating to version 7.0.7 the System.Drawing library used through Telerik.Reporting throws the following error:

"InnerException {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.PlatformInitialize()    at System.Drawing.SafeNativeMethods.Gdip..cctor()    --- End of inner exception stack trace ---    at System.Drawing.SafeNativeMethods.Gdip.GdipCreateBitmapFromScan0(Int32 width, Int32 height, Int32 stride, Int32 format, IntPtr scan0, IntPtr& bitmap)    at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)    at System.Drawing.Bitmap..ctor(Int32 width, Int32 height)    at Telerik.Reporting.Drawing.Unit.GetDotsPerInch()    at Telerik.Reporting.Drawing.Unit.ResetDpiSettings()    at Telerik.Reporting.Drawing.Unit..cctor()} System.TypeInitializationException"

"System.Drawing.Common is not supported on non-Windows platforms. See https://aka.ms/systemdrawingnonwindows for more information."

Until version 7.0.7 of .NET Core I was able to work around this issue using a third party Nuget package:
https://github.com/curiosity-ai/libgdiplus-packaging

Could you please address this issue as soon as possible?

With regards,
Hans Sixhöj
A Perfect Day AB
https://www.billingpoint.se

I spent three hours of my day trying to follow all your outdated documents only to stumble across this.

You really need to make sure this is spelled out on your pages, and while you are there, clean up all the outdated ones.

 

 

Hello Dimitar,

May I trouble you please with responses to my 2 below questions? My team is trying to make a decision whether we should move to .NET 6 or .NET 7, and it all hangs on this issue with Telerik Reporting.

Thanks again for your help

Hello Dimitar,

Now that Skia will or can be used instead of GDI, is it fair to say that going forward we won't run into this same issue with new versions of .NET (e.g. .NET 8)? I ask because it was a curveball that it works on .NET 6 but not .NET 7.

And also, can you please confirm (or deny) that things are on track still for having this fix for R3 2023?

Thank you

Hello Dimitar,

Approximately when will R3 2023 be released?

Thank you

Hello, guys!

Could you please tell me if you currently have any plans in the roadmap to support Telerik Reporting for .NET 7 / .NET 8 on Linux? Are you already working in this direction?

Our solution is stuck on .NET 6 (Linux) because of the dependency on Telerik Reporting components and I would like to understand whether we should just wait for some near future or come up with some alternatives to bypass these dependencies.

Ivan:
Thank you for clarifying.  I'm not getting the felling this is getting the attention it deserves.  This issue has prevented us from upgrading to dotnet 7 and based on your timeline will cause us to miss the entire dotnet 7 release.  I can see missing the original release of dotnet 7 by a few months but this is a year late! 

Think about that, there is no support for dotnet 7 on Linux for Telerik Reporting and by the time support is released dotnet 8 will be out.  

Ivan:
Thanks for the additional information, can you clarify your statement for us?  Will we be able to swap out the engine GDI+ for Skia with the R2 2023 release?  That's what it sounded like you were saying but then you said everything should work in R3.

Hi,

any new decisions you can share with us yet? This is currently holding us back from moving to NET7 as well.
This is getting harder for me to defend especially because this here is the only issue about it and it is still marked as "Unplanned".

NET8 might still be months away, but I imagine moving to a different rendering library is a months long endeavor to get right as well.
So any (technical) news or any alpha version to test would be very appreciated.

@Dimitar that is true IF you are using Telerik Reporting with .Net 6 as your example shows, however if you are using Linux and .Net 7 your example fails to load.

 

@Milen any update on .Net 7 and Linux support for Telerik reporting are you still planning on May of 2023?

@Sam, I know it's not LTS but this doesn't mean that is not ready for production, its support ends in May 2024. Our plan was to move to .net 7 this year and to .Net 8 in Dec 2023.

Furthermore, .net7 runtime is much faster in some areas and it has a lot of new features that we want to adopt for current and new versions of our system we planned for January.

Ado

 

 

 

@Ado,

Have you considered that .NET 7 is NOT long term service and .NET 6 is? Is skipping .NET 7 until a new LTS version comes a possibility for you?

Cheers.

I'm discovering now that we can't move our system on k8s to .net7 because Telerik reporting is not working on Linux.

I know that it maybe be challenging to swap the GDI library with SkiaSharp but it should have been planned ahead of time as GDI+ itself is a really ancient graphics library with a lot of issues.

We planned to move from .net6 to .net7 before the end of the year, a big system with a lot of microservices and many people involved: a lot of work is wasted now.

As a long Telerik customer, I feel that I must have been informed with a direct email, even more than one email, ensuring that all of us (your customers) were clearly aware of such a giant issue.

Sorry for the complaint,

Adolfo Marinucci

 

 

We deploy our apps to Azure App Service for Linux.  We will likely ignore .NET 7, since Microsoft won't give it Long Term Support (LTS).  However, we will very likely adopt the next following (LTS) version after .NET 7.

Milen:
We deploy our application to Linux via docker.  Right now our base image is Ubuntu. 

Actual Image: mcr.microsoft.com/dotnet/aspnet:6.0-focal.

We tried alpine a few times with little luck due to dependencies for Telerik Reporting, so that is another one we would be very interested in.  With Azure AKS now supporting ARM that is another area of interest for our runtime.

Milen, would it be possible for you share updates on a regular basis?  This will help us also plan for our .Net 7 upgrade alongside yours.

i am running the reporting code in a Linux container also.

We pass Telerik images for our reports and lack of System.Drawing.Common is going to break this in .Net 6 and going to be dead broke in .Net 7

For those unaware.. you can add this into your runtimeconfig.template.json to get Systme.Drawing.Commin working on .Net 6

    "configProperties": 
    {
      "System.Drawing.EnableUnixSupport": true
    }

This workaround will go away in .Net 7

We absolutely must have the ability to print images using Telerik Linux containers.

I can imagine this is a nightmare for the Progress Architects.

However, from a business standpoint this has to be in the product for us to continue using it.

As this is your dependency, I am not concerned with how you implement it.

 

 

 

 

 

We run all our applications in custom Linux containers on AWS just to support your reporting libraries.

This will be vital to be able to go to .NET 7.

 

 

 

 

Chiming in here,

Please see for reference -> https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only

Currently, we use Telerik reporting extensively on Linux. We recently upgraded several nuget packages that caused System.Drawing.Common to be updated to file version 6.x.x. According to the article above, in order to continue to use System.Drawing.Common under .NET 6 on Linux, we needed to add a runtime switch. This did indeed fix the exception.

However, this switch is gone in .NET 7.0. Microsoft's recommendation is to use:

• ImageSharp
• SkiaSharp
• Microsoft.Maui.Graphics

It's likely that Maui.Graphics is the strategic choice, given its ability as a complete cross platform library. My vote would be for Maui as a replacement, but I'll take anything as long as we can continue to use Telerik reporting on .NET 7.0.

Cheers,
Sam.

 

Hi All,

We also have similar problem. Our project based on .net6 and we are planning to use reporting in Linux environment.

When you are planning to improve Telerik Reporting rendering behavior on Linux machines? or when you expecting to use SkiaSharp library.

 

Thank you,

we will renew our license if you will do it

Thanks for the update. This is one I'm keenly interested in.

For reference, my use-case is with Azure Functions. Being able to host in Linux would enable us to adjust our hosting tier to much higher performance for the same cost (currently on Windows hosted). Although when I think about again, being able to fully drop the GDI dependency would also let us move to the dynamic serverless tier (which blocks most GDI access).

I understand that it's a large change and you can't give a commitment or timeline, but this feature would be huge for us - the further ability to run Telerik reports easily in more environments.