Welcome Guest Search | Active Topics | Sign In | Register

.NET Core support Options
François ROSSELLO
Posted: Wednesday, June 1, 2016 6:30:39 AM
Rank: Newbie
Groups: Member

Joined: 5/26/2016
Posts: 1
Does your components run on .NET Core ?

See here : https://dotnet.github.io/
Lastest version here : https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/


In that case, it should run on Windows, Linux and iOS :
•Red Hat Enterprise Linux 7.2
•Centos 7.1
•Debian 8.2+
•Ubuntu 14.04 (16.04 support is coming at RTM)
•Linux Mint 17+
•OS X 10.11
•Windows 7+ / Windows Server 2012 R2+
•Windows Nano Server TP5

That feature is more and more asked by customers.

If you don't support it yet, have you a road map about it ? Is it planned ?

eo_support
Posted: Wednesday, June 1, 2016 10:49:15 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,066
Hi,

We have no plan to support .NET Core for now. Internally our products rely heavily on Windows APIs. That part is not portable to other OS. As such there is no point for us to support .NET Core until that part is portable.

Thanks!
Nathan Smith
Posted: Thursday, August 17, 2017 1:01:22 PM
Rank: Member
Groups: Member

Joined: 7/31/2012
Posts: 10
Any update on plans given that .net core 2/.net standard 2 are now RTM?

dotnet core on windows should be possible now given that many other api that where previously missing are now back.

What I think would be an interesting and semi reasonable scenario to look into would be targeting a windows based nano server container.
https://docs.microsoft.com/en-us/windows-server/get-started/nano-in-semi-annual-channel

It does not run the full .Net Framework, only .net Core for windows but should provide many operating system api while still maintaining a small base image size.
https://github.com/dotnet/dotnet-docker/blob/master/2.0/runtime/nanoserver/amd64/Dockerfile

For comparison.
The full framework container based on server core is about 6GB compressed
https://hub.docker.com/r/microsoft/dotnet-framework/tags/

The dotnet core version (2.0.0-runtime-nanoserver) is 420mb
https://hub.docker.com/r/microsoft/dotnet/tags/

I understand this is a non trivial change and until now .net core was an unstable target from a product support perspective but hopefully that should be improving fast.

FYI..
When EO.PDF is currently called in .net core on windows it throws with:
System.IO.FileNotFoundException occurred
HResult=0x80070002
Message=Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Since this is really my only blocking dependency, will probably just move the EO.PDF out of web project into back end service that just renders html string to pdf but even that back end could benefit greatly from the reduced footprint.
eo_support
Posted: Thursday, August 17, 2017 3:23:03 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,066
Hi Nathan,

Thanks for the detailed information. Please see here for the current status of .NET core support:

https://www.essentialobjects.com/doc/common/dotnetcore.aspx

As for now, it still needs the full framework to run.
Voicebooth Ltd
Posted: Friday, September 29, 2017 4:31:06 AM
Rank: Member
Groups: Member

Joined: 7/17/2016
Posts: 17
Just wanted to also throw in some encouragement towards having a native .NET Core version of the PDF component. As we look ahead to the various .NET roadmaps, .NET Core's ability to run on Linux-based operating systems makes it very attractive for us try and start converting our own platform of services over to .NET Core.

As we look at our list of third-party components that we use, bit by bit they're all starting to catch up with support for .NET Core, and it would be great to ultimately see a fully .NET Core native version of EO.PDF.


Alvaro
eo_support
Posted: Friday, September 29, 2017 8:55:52 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,066
Voicebooth Ltd wrote:
Just wanted to also throw in some encouragement towards having a native .NET Core version of the PDF component. As we look ahead to the various .NET roadmaps, .NET Core's ability to run on Linux-based operating systems makes it very attractive for us try and start converting our own platform of services over to .NET Core.

As we look at our list of third-party components that we use, bit by bit they're all starting to catch up with support for .NET Core, and it would be great to ultimately see a fully .NET Core native version of EO.PDF.


Alvaro


Thank you very much for your feedback. Running EO.Pdf on Linux is not possible right now because EO.Pdf contains an embedded browser engine for its HTML to PDF feature. This browser engine is based on Google's Chromium project and it can only be compiled to native code, which can not be shared between Windows and Linux platform like managed code. This means its not possible for us to have a single .NET Core distribution to support both platforms. The current version of EO.Pdf only contains the native code for Windows platform.
NavaraTX
Posted: Wednesday, May 23, 2018 3:17:51 PM

Rank: Member
Groups: Member

Joined: 6/25/2013
Posts: 15
When we try this "<TargetFrameworks>netcoreapp2.0;net461</TargetFrameworks>" in our .NET Core 2.0 application we get the following errors.

Package Microsoft.AspNetCore.All 2.0.5 is not compatible with net461 (.NETFramework, Version=v4.6.1) / win7-x86. Package Microsoft.AspNetCore.All 2.0.5 supports: netcoreapp2.0 (.NETCoreApp, Version=v2.0)

Package Microsoft.AspNetCore.All 2.0.5 is not compatible with net461 (.NETFramework, Version=v4.6.1) Package Microsoft.AspNetCore.All 2.0.5 supports: netcoreapp2.0 (.NETCoreApp, Version=v2.0)

The type or namespace name 'Cookies' does not exist in the namespace 'Microsoft.AspNetCore.Authentication' (are you missing an assembly reference?)

The type or namespace name 'OpenIdConnect' does not exist in the namespace 'Microsoft.AspNetCore.Authentication' (are you missing an assembly reference?)

The type or namespace name 'OpenIdConnectOptions' could not be found (are you missing a using directive or an assembly reference?)

The type or namespace name 'ResponseCompression' does not exist in the namespace 'Microsoft.AspNetCore' (are you missing an assembly reference?)
Nathan Smith
Posted: Wednesday, May 23, 2018 4:22:36 PM
Rank: Member
Groups: Member

Joined: 7/31/2012
Posts: 10
I'm just a user subscribed to this thread but removing the netcoreapp2.0 and targeting only net461 would probably work.
<TargetFrameworks>net461</TargetFrameworks>
What you posted is trying to target both and the library does not support dotnet standard.
NavaraTX
Posted: Wednesday, May 23, 2018 4:39:38 PM

Rank: Member
Groups: Member

Joined: 6/25/2013
Posts: 15
Nathan Smith wrote:
I'm just a user subscribed to this thread but removing the netcoreapp2.0 and targeting only net461 would probably work.
<TargetFrameworks>net461</TargetFrameworks>
What you posted is trying to target both and the library does not support dotnet standard.


Thanks! It helped solve some of the errors, just not the following 2:

Package Microsoft.AspNetCore.All 2.0.5 is not compatible with net461 (.NETFramework, Version=v4.6.1) / win7-x86. Package Microsoft.AspNetCore.All 2.0.5 supports: netcoreapp2.0 (.NETCoreApp, Version=v2.0)

Package Microsoft.AspNetCore.All 2.0.5 is not compatible with net461 (.NETFramework, Version=v4.6.1) Package Microsoft.AspNetCore.All 2.0.5 supports: netcoreapp2.0 (.NETCoreApp, Version=v2.0)
Nathan Smith
Posted: Wednesday, May 23, 2018 5:47:11 PM
Rank: Member
Groups: Member

Joined: 7/31/2012
Posts: 10
I think if your targeting only 461 you can't target the uber meta package Microsoft.AspNetCore.All.
You have to target the individual components. Probably about 8 things don't remember which MVC, etc...
eo_support
Posted: Thursday, May 24, 2018 9:08:37 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,066
Hi,

Thanks for sharing. You can find details about .NET Core support here:

https://www.essentialobjects.com/doc/common/dotnetcore.aspx

The key is you must target the full .NET Framework instead --- which means the product in fact will not run on .NET Core. The documentation provided is only aim to help you to compile a .NET Core project with EO product, it still needs to target the full .NET framework at runtime.

Thanks!
NavaraTX
Posted: Thursday, May 24, 2018 10:06:19 AM

Rank: Member
Groups: Member

Joined: 6/25/2013
Posts: 15
eo_support wrote:
Hi,

Thanks for sharing. You can find details about .NET Core support here:

https://www.essentialobjects.com/doc/common/dotnetcore.aspx

The key is you must target the full .NET Framework instead --- which means the product in fact will not run on .NET Core. The documentation provided is only aim to help you to compile a .NET Core project with EO product, it still needs to target the full .NET framework at runtime.

Thanks!


Thank you, we may just have to use another product. We have used this product in WinForms for years now, but we are now rebuilding our app in .NET Core.
eo_support
Posted: Thursday, May 24, 2018 10:26:26 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,066
NavaraTX wrote:
Thank you, we may just have to use another product. We have used this product in WinForms for years now, but we are now rebuilding our app in .NET Core.


No problem. If you use HTML to PDF feature, then it's unlikely any matured commercial product will work on .NET Core. This is because any "true" HTML to PDF converter needs to run a browser engine inside and a browser engine is an extremely complex piece of software that is impossible to run on .NET Core. One exception to this is if they use IE pre-installed on the system as their browser engine. However this will expose their user to issues such as updating IE breaking their product. Because of this mature HTML to PDF product must have an embedded browser engine and this is the key obstacle to support .NET Core.

If you do not use the HTML to PDF feature, then you should be able to find alternative on the market to support .NET Core.
Voicebooth Ltd
Posted: Tuesday, December 4, 2018 8:42:58 AM
Rank: Member
Groups: Member

Joined: 7/17/2016
Posts: 17
Hi guys,

A quick nudge to see whether there's any plans to natively port EO.PDF to dotnet core / .NET Standard.

I understand the challenge of requiring various windows-specific components as it stands - my understanding is that EO.PDF uses the Chromium engine to render content, so presumably this is portable to Linux/MacOS?

We've started porting our products over to dotnet core and will soon encounter the point when we need to decide how to render HTML to PDFs, and unfortunately EO.PDF will no longer be working for us at this point. Our new products are all hosted on various Linux distros, as we look to get away from Windows hosting.


Alvaro
eo_support
Posted: Tuesday, December 4, 2018 11:11:08 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,066
Hi,

We do plan to officially support .NET Core 3.0 once it's available. However we do not have any plan to support non-Windows platform in the near future. While the Chromium browser engine indeed supports other OS but all the code on our side is still very Windows specific and currently we do not have sufficient resource to port that part to other platform. As such unfortunately I do not see a non-Windows version of our product in the near future.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.