Skip to content
This repository has been archived by the owner on Apr 29, 2022. It is now read-only.

Chart not drawn on client-side blazor in .netcore 3.0 #93

Closed
patrickhacens opened this issue Sep 25, 2019 · 10 comments · Fixed by #98
Closed

Chart not drawn on client-side blazor in .netcore 3.0 #93

patrickhacens opened this issue Sep 25, 2019 · 10 comments · Fixed by #98
Labels
bug Something isn't working documentation Improvements or additions to documentation

Comments

@patrickhacens
Copy link

Describe the bug

Chart on client-side is not rendered and the following error is shown on the browser console

WASM: Error while setting up chart: Constructor on type 'System.ComponentModel.ReferenceConverter' not found.

Which Blazor project type is your bug related to?

  • Client-Side

Which charts does this bug apply to?

Line Chart but i had not the time to test on them all

To Reproduce

Steps to reproduce the behavior:

  1. Using this version of ChartJSBlazor '0.10.3-preview'.
  2. Using .net core 3.0.0
  3. Run a copy of the LineLinearExample from commit 80ce217.

Expected behavior

The chart to be drawn unto the screen

Correction found

Searching a bit I found a solution on this link JamesNK/Newtonsoft.Json#2020, it seems to be a problem with Newtonsoft.Json but I'm not sure if it should be corrected by them

//the following line on the page/component that renders the chart corrected to the spected behavior
@using System.ComponentModel;
private ReferenceConverter ReferenceConverter = new ReferenceConverter(typeof(ChartJsLineChart));
@patrickhacens patrickhacens added the bug Something isn't working label Sep 25, 2019
@MindSwipe
Copy link

Can you try on the currently newest commit 8b074d0?

@SeppPenner
Copy link
Contributor

This is the workaround I found: #18 (comment). I don't know what we can do to fix this...

@Joelius300
Copy link
Owner

Joelius300 commented Sep 26, 2019

Thank you for the issue. This is a known issue. Details (as much as we know currently) can be found here.

Closing this for now since AFAIK the problem isn't with our library but with json.net. If this is not correct and you know how we can fix the issue, please tell us :)

@SeppPenner should we include a link to the known issues page somewhere? Maybe here? Or just in the readme?
@patrickhacens do you have an idea where to put a link so you could've found it before opening an issue (not a problem, I'm just trying to make things easier in the future)?

@SeppPenner
Copy link
Contributor

@SeppPenner should we include a link to the known issues page somewhere? Maybe here? Or just in the readme?

In both, I guess? Would make the most sense.

@patrickhacens
Copy link
Author

@MindSwipe there are no diffs from the template source file in both commits

@Joelius300 I think i would put it on the usage section on the main readme.md as an observation for those who will use blazor client-side

@SeppPenner
Copy link
Contributor

@Joelius300 You should keep this open just for reference (That we don't forget to document it).

@Joelius300 Joelius300 reopened this Sep 27, 2019
@Joelius300 Joelius300 added the documentation Improvements or additions to documentation label Sep 27, 2019
@SeppPenner
Copy link
Contributor

This is now documented under https://github.com/Joelius300/ChartJSBlazor/wiki/Known-issues. I will update the readme as well.

@Alexikik
Copy link

The correction stated in the post helped me. My problem was with the Syncfusion component "Schedule".

Thank you!

@SeppPenner
Copy link
Contributor

The correction stated in the post helped me. My problem was with the Syncfusion component "Schedule".

Thank you!

Interesting that this occurs with other vendor libraries as well. I didn't yet see this with Telerik yet.

@Joelius300
Copy link
Owner

Btw this issue was related to the linker thing I deemed unnecessary, sorry about that. Using the linker is a workaround because the client-side version strips the DLLs in order to minimize the size of the payload sent to the client. Using the linker you can prevent it from removing this constructor which is probably only accessed via reflection and therefore it thinks it can safely remove it.

We'll add the workaround back in in a future version (not in this repo of course).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working documentation Improvements or additions to documentation
Projects
None yet
5 participants