Looks like a typo in SerializerHelper.ParseReportMeta
A few days ago my jsReports started throwing an exception. I am running in the "remote" mode - ASP.NET Core Web application invoking jsReport running as a separate application. I have
jsreport.Typesinstalled. I can see that report gets submitted and executed successfully.
However, after return I am getting the following exception:
Method not found: 'Void jsreport.Types.ReportMeta.set_ReportPernamentLink(System.String)' at jsreport.Shared.SerializerHelper.ParseReportMeta(IDictionary`2 meta) at jsreport.Shared.SerializerHelper.ParseReportMetaFromHeaders(IDictionary`2 headers) at jsreport.Client.ReportingService.ReportFromResponse(HttpResponseMessage response) at jsreport.Client.ReportingService.RenderAsync(String request, CancellationToken ct)
ReportMeta.ReportPermanentLinkas opposed to
SerializerHelper.ParseReportMeta. Should be easy to fix - although I don't understand how it worked until now...
UPDATE: The problem is apparently in new versions of jsreport.Shared. Reverting jsreport.Shared to 2.0.0 and jsreport.Types to 2.2.6 (not sure if this was necessary) provided the temporary solution, and explained why it worked before
Based on the error, it seems you had
These are not compatible. If you update jsreport.Shared to 2.0.1 it should work.
Or as you have done downgrade jsreport.Types to 2.2.6
No. I had a problem with Shared 2.0.1 and Types 2.2.7... after downgrading both the problem went away. As I said in the original post - the problem is pretty obvious ;)
The error says that the jsreport.Shared is looking for property
ReportPernamentLinkand it can't find it in jsreport.Types.
You can see in the code that the jsreport.Shared 2.2.7 has this typo fixed and uses
This means that the error you posted should not be thrown when using 2.2.7.
I would not argue here if it wouldn't work for me.
OK, I think I know what happened... We had
jsreport.Types2.2.7 installed, but we did not have
jsreport.Sharedinstalled at all (it says "internal" and it seems that it worked fine without it being explicitly installed). I don't know how package dependencies are configured - but it looks like we had earlier version reference Shared 2.0.0; and after we upgraded Types - it continued to reference 2.0.0, rather than force upgrade to 2.0.1
You are right - we could install Shared 2.0.1 explicitly (which we just did, and it indeed works fine), or (what we did) we reverted Types to 2.2.6 that continued to use Shared 2.0.0 implicitly.
Thank you, it's all good now!
Yes, I think
jsreport.Shared2.0.0 so that was the implicit reference.
Glad it is clear now.