Yes, the server is 64 bits.
Yes, node.js is intalled on the server
I was trying to remove Crystal reports dependencies from a project via nuget and when i deploy it it seems that it cannot create the jsreport binary for some reason.
If i deployed it without removing the crystal dependencies everything worked as expected (weird i know...)
Anyway, i just manually removed the dependencies and just to be sure, changed the default TempDirectory to point to:
Path.Combine(System.Web.Hosting.HostingEnvironment.MapPath("~"), "jsreport", "temp");
and it seems to be working fine
Just for the record:
When render async is called (and you do not specify a TempDirectory in the configuration of the reporting service) it tries to create a jsreport folder inside the Windows/Temp folder (if the apppool identity in iss is the default one) or inside Users/XXXX/AppData/Temp and Windows/Temp (if the apppool identity is not the default one),
this jsreport temp folder contains the binary, so if this problem happens be sure to check the size, it should be ~35mb AND NOT 0kb
Note: other reason why this error could happen, is because one of its the depencies is not correctly set in a <dependentAssembly> tag. For example, jsreport.Client v2.0.2 uses System.Net.Http >= 4.3.2. If you have something like:
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-220.127.116.11" newVersion="18.104.22.168" />
inside your web.config or app.config, this error may arise. So, be sure to check that the dependencies are updated
i don't think we should keep commenting in this conversation, we are spamming original user that opened this thread which has a problem with .net not something related to your case. so please open an issue here to continue conversation.
the migration utility is not designed to work in all possible cases, it is hard to make a tool to work in all cases and even more difficult because jsreport v2 has a lot of internal changes, the utility is designed to work on the mainstream normal jsreport installation and according to what you are describing and your previous topics looks like your project was using some custom extensions in v1.10 so it qualifies as not normal jsreport installation, because of that there is a chance that something weird is happening after you run the migration in your project. it will be faster for me if i can take a look at your v1.10 project (before the migration), you can temporary setup a public repository on github and share it with me so i can take a look at your project, if you are not able to share your project in public you can send me a zip file to my email firstname.lastname@example.org with the source of your jsreport v1.10 (but please make sure to not include in the zip file the node_modules folder because it will increase the zip file size a lot). as i said above, please open an issue in jsreport repository and let's continue the conversation there
If you find some spare time, it would be great to reference a full configuration file with all possible options, as for now information is scatterred here and there and some are missing. (Expanding this page would be awesome : https://jsreport.net/learn/configuration)