jsreport single file executable .exe versioning issue(need stable .exe version)

yusufkumarkiri

Hello team, @jan_blaha ,
Good morning ,we are using jsreport single file executable (for jsreport server) and rendering report from .Net core web application. It works fine with latest .exe available on githut(https://github.com/jsreport/jsreport/releases).
But once new release available for .exe, our application will stop working and we have to download and install new exe on server and it works again.
This is very unstable and impacting work.
Please can you suggest is there any way to get stable version of .exe which works all the time.
It will be great if you suggest any other best option for using jsreport server for windows .

Below are few application details:
.Net version -.Net core 6, .Net framework 4.8
Hosting - On windows server
jsreport server- installed single executable on window server
Output- Report render in pdf format

sample code from web application:

ReportingService rs = new ReportingService("http://localhost:5488");

var customReport = rs.RenderAsync(CustomRenderRequest).Result;
customReport.Content.CopyTo(File.OpenWrite("customReport1.pdf"));

private static RenderRequest CustomRenderRequest = new RenderRequest()
{
Template = new Template()
{
Content = File.ReadAllText("Pathofhtmlfile.html"),
Engine = Engine.Handlebars,
Recipe = Recipe.ChromePdf
},
Data = new
{
message = " Testing jsreport for .NET!!!"
}
};

Error details:
Below error occurs after a month or so (specially when there is new .exe available), once we install new exe it works fine again.

Error message:
spawn UNKNOWN
Error: spawn UNKNOWN
at ChildProcess.spawn (node:internal/child_process:412:11)
at Object.spawn (node:child_process:698:9)
at Object.spawn (pkg/prelude/bootstrap.js:1963:27)
at BrowserRunner.start (C:\snapshot\jsreport\node_modules\puppeteer\lib\cjs\puppeteer\node\BrowserRunner.js:119:34)
at ChromeLauncher.launch (C:\snapshot\jsreport\node_modules\puppeteer\lib\cjs\puppeteer\node\ChromeLauncher.js:76:16)
at async createBrowser (C:\snapshot\jsreport\packages\jsreport-chrome-pdf\lib\chromePoolStrategy.js:98:26)
at async allocateBrowser (C:\snapshot\jsreport\packages\jsreport-chrome-pdf\lib\chromePoolStrategy.js:113:5)
at async getBrowser (C:\snapshot\jsreport\packages\jsreport-chrome-pdf\lib\chromePoolStrategy.js:23:30)
at async C:\snapshot\jsreport\packages\jsreport-chrome-pdf\lib\conversion.js:11:19
at async execute (C:\snapshot\jsreport\packages\jsreport-chrome-pdf\lib\chromePoolStrategy.js:20:22)

Please share your suggestion on this issue to make it stable for all time.

Thank you !!
Yusuf Kumarkiri

jan_blaha

Do you use windows service to keep jsreport running?

I don't think this problem could have something to do with the new releases. In fact, there is no network communication if you don't apply for a license. Do you use a free license or a license key?

The jsreport.exe extracts into the user's temporary directory chrome binary and it can happen OS or something removes it. This causes the mentioned error. We have added some recovery code to get over this in jsreport 3.8.0.
However, it may help to instructs jsreport to use specific tempDirectory at specific folder.
This can be done using command arg

jsreport start --tempDirectory=someFolder

yusufkumarkiri

Hello @jan_blaha ,
Thank you for quick response.

Yes we use windows service to keep jsreport running.
Yes, we are using license key for jsreport .(Does it cause any such kind of issues , if we use license and without license version ?).

We will monitor if we face same issue in future and update you.

Appreciate your support

jan_blaha

The mentioned error spawn UNKNOWN should have nothing to do with the licensing.
Either something corrupted unpacked chrome in temp, or something blocks its start.

Yes, keep us posted. Thank you

yusufkumarkiri

Thank you for your response. We will monitor for same issue again and update you it occurs again.
Thank you.

dhernandez

Hello! Is there any progress on this matter? I'm experiencing the same issue. The error seems to be random (we're not sure if it's related to when there's a new version available, as Yusuf mentioned). Currently, we have a specific folder configured as tempDirectory.
We've been encountering the same error for several versions now.

Thanks!

admin

We haven't been investigating further because we can't replicate it. I know you mention it is random, but anyway, no chance to provide us with some hints to replicate it? Also zipped content of the tempDirectory when this happens could help us maybe.

dhernandez

Thanks for the response. We are trying to replicate it, when it happens again we will share some details.