jsreport single file executable .exe versioning issue(need stable .exe version)
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;
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!!!"
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: 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 !!
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?
jsreport.exeextracts 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
tempDirectoryat specific folder.
This can be done using command arg
jsreport start --tempDirectory=someFolder
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
The mentioned error
spawn UNKNOWNshould 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
Thank you for your response. We will monitor for same issue again and update you it occurs again.
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.
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.
Thanks for the response. We are trying to replicate it, when it happens again we will share some details.