Running on Linux

[vertonghenb]

Since it's far cheaper to run on Linux, it might be beneficial to start looking to make this package run on Linux devices.

@arichika Any thoughts?

[arichika]

The Windows has a great philosophy for compatibility. In terms of development productivity, I think that the Windows ecosystem remains low cost.

By the way, I think linux support is not difficult.

Just fix it like this,

RotativaCore/src/RotativaCore/WkhtmltopdfDriver.cs

Line 8 in 366f916

RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? "wkhtmltopdf.exe" : "wkhtmltopdf";

If wkhtmltopdf works correctly, it will ... work. work? I think it works with minor modifications.

The most difficult part is to make sure that the latest wkhtmltopdf works correctly in various linux environments.

[vertonghenb]

mmm gonna give a spin later this week, I was looking at the exact same line.
Well if you deploy to an Azure App Service the (basic tier) the costs of linux is divided by 7, thats why :)

[vertonghenb]

@arichika good news, just tried your fork in a Azure Linux Self contained deployed and it works for the view with model, the others fail, don't know why yet but I think it has to do with the new routing system. The example Linux deploy can be found here.

Will you merge it into master and create a new deployment ?

[arichika]

@vertonghenb thank you so much for good works.
I am using Docker for Windows and checking the operation with the latest wlhtmltopdf.
Please wait a little more. thank you.

[vertonghenb]

@arichika ok sure, let me know if you need anything.

[arichika]

I clarified some problems and solutions.

One, Generating url for internal action methods with port num.

For example, In the time that ActionAsPdf method calls self hosted action method using IUrlHelper.Action(), library will generated for internal refalencing url with additional ports number.

In the container like docker, the port number is explicitly disclosed, There is a problem here.

The program IUrlHelper.Action() generates a URL on port SomeDebugginPortNumber or SomeIntrnalPortNumer in container, but at that number, the container is not waiting for an external connection.

Since the started WkhtmlToPdf process is started by a process different from Container, it must be accessed with the published port number.

But unfortunately, the program doesn't know which port number will be started and which port number will be EXPOSE.

In short, we will need the following improvements:

Information about the host to connect to must be given as an external configuration value under the general Linux Container environment, even if it is your own action method.

Two, The Problems arounds WkHtmlToPdf Binaries

The latest WkHtmlToPdf has separate installation packages for each Linux distribution. It seems that the prerequisite packages required to work vary depending on the environment. I think that it is difficult to ensure proper operation between the test environment (eg Docker for Windows) and the execution environment (eg AzureWebApps for Linux) simply by placing the Wk binary in the project.

Also, since the procedure for installing dependent programs with Dockerfile is a common method, the WlHtmlToPdf binary should not be included in the Web project, and should be controlled by the execution environment administrator.

Solutions / Tasks

• The installation of WkHtmlToPdf is specified in Dockerfile.
• The host name and port number of the connection destination should be given from the outside. The default value guarantees the current operation for Windows.

Please wait a little while longer.