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

Why not .net build-in code generator? #451

Closed
GihanSoft opened this issue Jun 29, 2022 · 4 comments
Closed

Why not .net build-in code generator? #451

GihanSoft opened this issue Jun 29, 2022 · 4 comments

Comments

@GihanSoft
Copy link

This wonderful package use a cli tool for code generation. but why not using build-in .net code gen?
It won't add files in project and doing it auto in build process.

@devbased
Copy link
Contributor

I think in the case of the mapper, the user should be able to save the generated models in source control. And dotnet generator has a problem with that. You can specify <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> and <CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath> but this will emit output from any generators not just from the Mapster.
Not sure if this has been resolved.

@GihanSoft
Copy link
Author

@devbased not actually. Auto-gen files are step-able and visible. The only reason can be customizing Auto-gen code and I thing it's not good thing to do.

@jvmlet
Copy link

jvmlet commented Jan 23, 2023

@devbased , the rule of thumb is to NOT commit generated files to SCM.
For those who also can't see generated files being committed to git , here is the workaround :

<Target Name="Mapster" BeforeTargets="BeforeBuild;BeforeRebuild" Condition="'$(EnableMapsterCodeGen)' == 'true' And '$(ONCE)' != 'TRUE'">
        <PropertyGroup>
            <MapsterGeneratedFiles>$(MapsterCodeGenDirectory)\*.g.cs</MapsterGeneratedFiles>
        </PropertyGroup>
        <ItemGroup>
            <Compile Remove="$(MapsterGeneratedFiles)" />
        </ItemGroup>
        <RemoveDir Directories="$(MapsterCodeGenDirectory)"/>
        <Exec Command="dotnet msbuild $(ProjectPath) -p:Configuration=$(Configuration)"
              EnvironmentVariables="ONCE=TRUE" />
        <Exec Command="dotnet tool update Mapster.Tool --global --version=8.3.0" />
        <Exec WorkingDirectory="$(ProjectDir)"
              Command="dotnet mapster mapper -o $(MapsterCodeGenDirectory) -a $(TargetDir)$(ProjectName).dll " />
        <ItemGroup>
            <Compile Include="$(MapsterGeneratedFiles)" />
        </ItemGroup>
    </Target>

This target removes the generated files and spawns another dotnet msbuild command to regenerate mappings during normal build.
If you adopt this approach, DO NOT reference generated classes from your code base, use only interfaces and have DI to discover classes that implements interface that is annotated with [Mapper] attribute :

Pseudo-Code:

allAsseblies.AllTypes.Select(type =>{
var i = type.Interfaces.FirstOrDefault(i->i.HasAttribute<MapperAttribute>());
return null==i ? null : new (i,type)
})
.WhereNotNull()
.ForEach(pair=>container.Register(pair.type).As(pair.i)

Usage :

<PropertyGroup>
    <EnableMapsterCodeGen>true</EnableMapsterCodeGen>
    <MapsterCodeGenDirectory>GeneratedMappings</MapsterCodeGenDirectory>
  </PropertyGroup>

@stagep
Copy link

stagep commented Jan 7, 2025

In order to identify issues that are still active, we are closing issues that we believe are either resolved or are dormant. If your issue is still active then please reopen. Thanks.

@stagep stagep closed this as completed Feb 3, 2025
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

4 participants