Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target .net standard 2.0? #182

Closed
Mek7 opened this issue Apr 11, 2024 · 8 comments
Closed

Target .net standard 2.0? #182

Mek7 opened this issue Apr 11, 2024 · 8 comments

Comments

@Mek7
Copy link

Mek7 commented Apr 11, 2024

Hello,
this library now targets the specific .NET versions such as .NET 5, 6, 7, 8.
If we want to reference it in a class library project, we will have to target .NET 8 as well, but for class libraries, .net standard is the recommended target.
Can your library target .net standard instead of the specific .NET versions?

@lkosson
Copy link
Owner

lkosson commented Apr 12, 2024

Hi. From preliminary experiments - it might be possible. I'm not sure how to deal with Microsoft.CodeAnalysis.VisualBasic references, though.

@lkosson
Copy link
Owner

lkosson commented Apr 12, 2024

There are two major problems when referencing .NET Standard - version-dependent references for Microsoft.CodeAnalysis.VisualBasic and no support for assembly unloading.

I have made some minor changes to allow compilation against .NET Standard 2.1 for Microsoft.ReportViewer.ProcessingObjectModel, Microsoft.ReportViewer.DataVisualization, Microsoft.ReportViewer.Common and Microsoft.ReportViewer.NETCore projects. Microsoft.ReportViewer.WinForms is completely out of scope because WinForms is not available in .NET Standard. Those changes disable dynamic assembly unloading, which means each report invocation will leak some memory.

If that's OK with you, change TargetFrameworks property of above mentioned projects to netstandard2.1 and build custom version of this package. You might also need to tweak Microsoft.CodeAnalysis.VisualBasic reference to match those of your product, bump up System.Drawing.Common version to 8.0 and remove System.Windows.Extensions reference.

@Mek7
Copy link
Author

Mek7 commented Apr 12, 2024

Thanks for your quick response. I will have to live with that my library also has to target a specific .NET version instead of .netstandard.

@ryanryanorient
Copy link

Support for .NET Standard is great, and while .NET 2.1 requires .NET 5+, I wish it would support .NET 2.0 so that it is better compatible with the .NET Framework

@lkosson
Copy link
Owner

lkosson commented Apr 18, 2024

For .NET Framework there is original Report Viewer.

@Mek7
Copy link
Author

Mek7 commented Apr 18, 2024

Sure, but not when you want to migrate from .NET Framework to .NET. Then, .NET Standard 2.0 is the only bridge between the two, where assemblies targeting .NET Standard 2.0 can be referenced from both.

@lkosson
Copy link
Owner

lkosson commented Apr 18, 2024

Fair enough. The problem is .NET Standard 2.0 is missing some APIs from System.Drawing namespace and don't support AssemblyLoadContext. In principle it might be possible to target .NET Standard 2.0 with ReportViewerCore, but that would require some tedious work for questionable gains.

Consider multi-targeting your assembly/package and compile it against .NET Framework and .NET from same codebase, but referencing ReportViewer and ReportViewerCore respectively.

@Mek7
Copy link
Author

Mek7 commented Jun 6, 2024

I went a different way - isolated the report rendering into a special web api application that renders the report and returns a byte array - so other code now has no direct references to the code that uses this library.
Yes, I also multi-targeted some of the other projects in my solution, because of Entity Framework, but that's a different story...
So I am closing this.

@Mek7 Mek7 closed this as completed Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants