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.

Sign up for GitHub

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

Jump to bottom

Remove Riok.Mapperly.Abstractions runtime dependency #685

Closed
latonz opened this issue Aug 28, 2023 · 2 comments · Fixed by #711
Closed

Remove Riok.Mapperly.Abstractions runtime dependency #685

latonz opened this issue Aug 28, 2023 · 2 comments · Fixed by #711
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@latonz
Copy link
Contributor

latonz commented Aug 28, 2023 •
edited
Loading

Rel. #666.

Mapperly provides configuration attributes in Riok.Mapperly.Abstractions. For reference handling, a default implementation of IReferenceHandler is also provided in Riok.Mapperly.Abstractions as PreserveReferenceHandler. The PreserveReferenceHandler is the only runtime dependency of the code generated by Mapperly (only if reference handling is enabled).
If reference handling is not used PrivateAssets="all" ExcludeAssets="runtime" can be set which eliminates the need of Riok.Mapperly.Abstractions as a runtime dependency.
We should improve the documentation on this (document PrivateAssets="all" ExcludeAssets="runtime" on the installation page) and try to eliminate the runtime dependency. Sadly we cannot set DevelopmentDependency=true, since this does not work for source generators.
Ideas on how to eliminate the runtime dependency on Riok.Mapperly.Abstractions:

  • Emit the PreserveReferenceHandler class from the source generator if reference handling is enabled
    • If the class is emitted as an internal class in a Mapperly namespace, this could lead to duplicated symbols when InternalsVisibleTo is set
    • The class could be emitted as a file scoped class. Mapperly would need to generate the class for each mapper using reference handling and would require C# language version 11.
    • The class could be emitted in a namespace which is dependent on the name of the assembly.
  • Create a new NuGet package Riok.Mapperly.ReferenceHandling which a user needs to reference when enabling reference handling.
@latonz latonz added documentation Improvements or additions to documentation enhancement New feature or request labels Aug 28, 2023
@latonz latonz mentioned this issue Sep 1, 2023
Merged
7 tasks
latonz added a commit that referenced this issue Sep 5, 2023
@latonz
feat: Remove runtime dependency on Riok.Mapperly.Abstractions (#711)
f26f026 
Creates a new Riok.Mapperly.Templates project with templates. Some Mapperly features may require such a template (currently only the reference handling). If such a template is required by a used Mapperly feature, Mapperly emites the template in a namespace which includes the name of the assembly of the target project. This is done to prevent collisions when using InternalsVisibleTo (see #685).
Currently the only themplate is the PreserveReferenceHandler which is emitted if reference handling is enabled for any mapper and the mapper does have mapper method definitions without a reference handling parameter and Mapperly needs to instantiate a IReferenceHandler.
@github-actions
Copy link

github-actions bot commented Sep 5, 2023

🎉 This issue has been resolved in version 3.2.0-next.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions
Copy link

🎉 This issue has been resolved in version 3.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: remove the Riok.Mapperly.Abstractions runtime dependency
1 participant
@latonz