Source Generators with IMapper Interface

[ismkdc]

Hello, I am using mapster with fec and I am very happy :)
But i am curious about something.. Is there any way for using source generators which is Mapster.Tool and IMapper interface?

So I want to still inject IMapper interface to my classes but I want use source generated mappings.

[EmreAka]

I too was searching for it. It would certainly be great to have!

[salihcantekin]

If there is Source Generator supports for IMapper, that would take Mapster a few steps up. It would be the most common library for AOT base apps. I'd like to contribute to this development tho!

[andrerav]

I think this is a great suggestion, however there may be a showstopper. Currently only netstandard2.0 assemblies can be used as source generators. Since Mapster and its constituent components are all net6.0/net7.0/net8.0 currently, I think it's currently not possible to run a source generator from Mapster. I might be wrong, this is just based on a quick readup on requirements for source generators, so I'm eager to hear your thoughts on this. It might be theoretically possible to bring netstandard2.0 back into Mapster, but it requires quite a few code changes since Mapster now relies on features not available in netstandard2.0.

[luizfbicalho]

I think that this is not an issue anymore

[DevTKSS]

@andrerav I’ve recently been looking into using Mapster.Tool as a dotnet tool together with source generator support. Based on your earlier comment, it seems the main blocker is still the requirement that source generators must target netstandard2.0.

Could you clarify which parts of Mapster rely on APIs that currently prevent introducing a netstandard2.0 project for the generator? Understanding the specific areas that would need adjustments would help contributors assess what’s required to make a generator feasible.

Breaking this down into smaller sub-issues would also make potential contributions much easier.

@stagep @DocSvartz — any additional insights are appreciated.

Thanks!

[DocSvartz]

@DevTKSS
The main problem is the availability of a maintainer who could handle the backport from the main branch to the Netstandard 2.0 branch and testing.
see this #655

[DocSvartz]

@DevTKSS Can you describe in more detail what exactly is required from Mapster?
As far as I understand, the initial question was about the following features:

1. Embedding IMapper in third-party source code generators?
2. Using MapsterTool's output as a source code generator?
3. AOT support?

[DevTKSS]

@DocSvartz I am not sure which of your list would be the equivalent, but I did understand "Source Generator" as Roslyn, like its used for Mvvm [ObservableProperty] .
Is this "AOT" for you? For me its simply Source Generator 😅
I not worked with AOT project properties by now for things like WASM but the benefit I estimate with a Source Generator is to be able to rely on the Dto's are created right after I would save the file of the attributed type so my other parts of my app could catch up this type and I could use it right up from there.
Compared to this, the Mapster.Tool we currently have is a dotnet tool executed from msbuild after build action.

I had no time to look deeper into implementing the output because I am still a bit unsure how to set up the attributes correctly for using it 😅

I think my main difficulty with the tool kind to do it is, that I create normally 'public partial record` definitions using primary constructor for Immutability and those would include already the required logic it needs at runtime.

The most annoying (because simply not interesting then a have-to-do task) part I am facing with this in my development is, I always have to additionally create:

• Json serializable type definition
• Dto type definition in case there are some properties the eventual consumer of my API (desktop or web not matters) should not get

The Wiki doesn't shows it actually and I not tryed out so far, if I can attach the attributes to the record definition with primary constructor to its property parameters, so I would need to try out 🤔
Maybe I will have to use the configuration way instead of attributes instead, but not came to try it out so far of this works to produce needed Dto's 😅

[DocSvartz]

Perhaps you simply need to divide the responsibilities:

1. Find a DTO generator that meets your needs.
2. Generate mappers between Entity and generatedDto using the Mapster tool.
   If you need the attributes used by the Mapster, it's much easier to separate them into a separate library that uses only NetStandard 2.0 so that the generator you use can add them?

[DocSvartz]

I think I've figured out what's going on in the Mapster tool :)
But it's still unclear how the will be configured mapping when the source generator is running :)

[DevTKSS]

@DocSvartz I don't think I will find time before tomorrow, planning to participate on the current Uno Platform AI Challenge from the past Webinar 😄 But maybe after this and - not sure if you are much into X-Mas? For me its only the 23rd 🎂 & 25th 🎄mainly - we could look together in this SourceGen thing.

Before they started the previous contest, I already tryed around a bit for how to create a Source-Generator, but found myself struggling to understand, how I would need to set up the:

• typeOf(TType)[...].GetConstructors with the DynamicDependency.* required Members except from the .PublicConstructors so it would pass Trimming

• Nested (local scoped) variables the code might need

• Using INamedSymbol was not available

• the Project I used to sample from used to reference include only the ../../specificFolder/*.cs so the source used Project aka "Attribute Project" did actually kept using NET8 in that case, which I would assume would be great, as it would give us more freedom to do whatever we want in there. <- Found myself stuck setting this up correctly my Generator netstandard2.0 Project linted the [Generator] because the Attribute Project was using higher version as it expected.

  But this problem could realistically coming from Copilot which I asked to generate the general implementation I could then extend on, potentially made issues. e.g. <LangVersion>latest</LangVersion> in Generator project <- Not recommended and potentially not even needed. Did not find a quick solution, so I put it back on the stack of things to try later 😄