Are you referring to this https://forum.jsreport.net/topic/288/deploying-solution-on-windows-server/24
I am already using the latest jsreport.local 1.1.2 and jsreport.binary 1.10.
I really could not find any solution on that post as to how to render reports using service identity under IIS.
Does JsReport local not work with Service Identity?
Is there a way to render pdf reports from Razor views by not using local jsreport in asp.net core web application?
I don't know. There is likely a way how to get html string from the razor page which you can afterwards easily convert into pdf using jsreport.
Unfortunately I am too busy to investigate this and I never used razor pages before.
If you find out how to get the html string form the razor page, you can use this code to convert it to the pdf.
var rs = new LocalReporting().UseBinary(JsReportBinary.GetBinary()).AsUtility().Create();
var report = await rs.RenderAsync(new RenderRequest()
Template = new Template()
Recipe = Recipe.PhantomPdf,
Engine = Engine.None,
Content = "The html you get from the razor page"
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-18.104.22.168" newVersion="22.214.171.124" />
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 email@example.com 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