Windows Server 2019 - JSReport Issues
I am building out an .NET Core application that is being hosted on Windows Server 2019 (64 bit). My development machine is running Windows 10 64-bit. I'm using JSReports local and everything works fine on my local machine, but after deploying the project to our development server we run into problems with the binary exes.
When hitting the endpoint of the application that generates the report, I get the following error:
JsReportBinaryException: Error rendering report: internal/child_process.js
After doing some digging, we found the following in the event viewer on the server:
The program or feature "\??\C:\Windows\TEMP\jsreport\compile\jsreport-2.4.0-H1DuB-TUV\WinRun.exe" cannot start or run due to incompatibity with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.
Research on these forums I've tried running the jsreport.exe from the command line using a simple in file but get the following results:
jsreport render --template.content in.html --out output.pdf A critical error occurred while trying to execute the render command: An error has occurred when trying to initialize jsreport (2). end of central directory record signature not found (1). caused by error (2) -> stack = Error: An error has occurred when trying to initialize jsreport at instance.init.then.catch ([eval]:71911:29) at tryCatcher (jsreportRuntime.js:44358:23) at Promise._settlePromiseFromHandler (jsreportRuntime.js:42379:31) at Promise._settlePromise (jsreportRuntime.js:42436:18) at Promise._settlePromise0 (jsreportRuntime.js:42481:10) at Promise._settlePromises (jsreportRuntime.js:42557:18) at _drainQueueStep (jsreportRuntime.js:39272:12) at _drainQueue (jsreportRuntime.js:39265:9) at Async._drainQueues (jsreportRuntime.js:39281:5) at Immediate.Async.drainQueues (jsreportRuntime.js:39151:14) at runCallback (timers.js:794:20) at tryOnImmediate (timers.js:752:5) at processImmediate [as _immediateCallback] (timers.js:729:5) caused by error (1) -> stack = Error: at jsreportRuntime.js:99415:14 at jsreportRuntime.js:99721:5 at jsreportRuntime.js:99001:7 at FSReqWrap.wrapper [as oncomplete] (fs.js:658:17)
Can anyone assist with getting this running? I suspect it may be because we are on Windows Server 2019, but I am surprised that that would cause these problems.
A quick edit: I copied the EXEs from my local dev machine to the temp directory on the development server and I do not get the compatibility issues with WinRun.exe, and in fact, get a new error:
JsReportBinaryException: Error rendering report: instance has been daemonized and initialized successfully
The compile directory in the temp folder was VASTLY different between my local machine and the development server. Any ideas why this would be?
I started a new VM in azure with Windows Server 2019 Datacenter edition.
I installed .net core runtime.
I published into folder this application https://github.com/jsreport/jsreport-dotnet-example-consoleapp
And I don't see any issues.
So there is likely no problem with Windows Server 2019 and jsreport compatibility.
Thanks for investing time into analyzing this deeper.
The binaries in compile directory got somehow corrupted as you found out.
I don't know how this can happen so far, maybe the first run which was extracting the binaries got interrupted for some reason.
Maybe some antivirus blocked it or something like that.
We will try to invest some time to make this more robust.
To your last error. Can you provide me more details?
Do you get the same error when running console demo?
Isn't there more information in the exception?
Sorry for the late response here but my days have been very busy. I think you are 100% correct that the binaries got corrupted. After deleting the folder and re-running the report, everything worked fine and I had zero issues deploying to another server. Not sure entirely what all is happening but deleting the folder and re-trying seemed to solve the issue.
Again, apologies for the delayed response - but I did want to follow back up on this to ensure other people might come across the (hopefully temporary) solution.
Thanks for your prompt response!