You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In cases where platforms are not supported, the SkiaSharp.Views.Forms package used to allow the use of a netstandard dll. This caused issues when using the WPF package or any other packages we add in the future. (see #1011)
As a result of this issue, we moved the netstandard dll to ref-only as it was intended in #1012. The packages now work correctly (no longer crashes), but breaks in cases where JUST the netstandard dll was desired. (see #1047).
To solve this, we need 2 assemblies - 1 for the shared bits and 1 for the platform bits. Right now there is one, and this will either break as in #1011, or as in #1047 . If we split the assembly, then we can solve both issues.
Although this may seem like a smaller issue, the code was originally designed to be a single dll and all the types are partially implemented in places. This is nice for a single dll, but not at all for split dlls.
The text was updated successfully, but these errors were encountered:
Moving this out of v1.68.2 as this is a bit more work (because the code was designed to be in a single dll) and it not particularly necessary at the moment with the bits in #1089
In cases where platforms are not supported, the SkiaSharp.Views.Forms package used to allow the use of a netstandard dll. This caused issues when using the WPF package or any other packages we add in the future. (see #1011)
As a result of this issue, we moved the netstandard dll to ref-only as it was intended in #1012. The packages now work correctly (no longer crashes), but breaks in cases where JUST the netstandard dll was desired. (see #1047).
To solve this, we need 2 assemblies - 1 for the shared bits and 1 for the platform bits. Right now there is one, and this will either break as in #1011, or as in #1047 . If we split the assembly, then we can solve both issues.
Although this may seem like a smaller issue, the code was originally designed to be a single dll and all the types are partially implemented in places. This is nice for a single dll, but not at all for split dlls.
The text was updated successfully, but these errors were encountered: