Enhancment Request Allow for changing Access Modifiers on configuration Classes

[jwyza-pi]

Would be nice if we could, via config, change the behavior of

EFCorePowerTools/src/Core/RevEng.Core.60/DbContextSplitter.cs

Line 108 in 2793e2a

sb.AppendLine(new string(' ', 4) + $"public partial class {entityName}Configuration : IEntityTypeConfiguration<{entityName}>");

to allow for it to write it out as a different access modifier. In my case, I wanted to make it internal instead of public.

Provide technical details

• EF Core Power Tools version: 8.1.391

• Exact Visual Studio version: NA

• Database engine: Azure SQL

• EF Core version in use: EF Core 8

• Is Handlebars templates used: no

• Is T4 templates used: yes

• Is a SQL Server .dacpac used: no

[ErikEJ]

Keep in mind that this is a preview feature, potentially to be replaced by a t4 template when EF Core 6 goes out of support

[jwyza-pi]

Interesting. When I looked, it didn't seem like the EF Core templates would generate a T4 template for the EntityTypeConfiguration. So I wasn't sure if efcore itself was going to continue to support T4 for that piece. (reference to the place they generate the templates: https://github.com/dotnet/efcore/blob/bb583a91d7269510ecb09a4466fee61bc62280d1/src/EFCore.Templates/EFCore.Templates.csproj#L26)

[ErikEJ]

Someone else created something see #1499

[jwyza-pi]

Given that Net 6 isn't being removed from this repo until March 2025 per #2476. That means that supporting the T4 approach won't happen before then correct? So we have at least 6 months before we'd have a way to handle this. Or if I were to turn off the DB splitting and pulled in the T4 template, would it "just work"?

[ErikEJ]

@jwyza-pi If have not tried the "would just work" scenario, but I doubt it.

Alernativly you can always do som script based post processing...

[jwyza-pi]

So, to the question of "just work", answer is no. The reason is that the ModelCodeGenerationOptions.RootNamespace needs to have a value and it's presently being set as null, even if names/root-namespace is set.

Even if I manually change that during runtime to pass it. It'll still fail since it'll generate the configs inside the dbcontext as well and also it will dump the config files into the same directory as the context rather than the configurations directory.

Soooo yeah, definitely won't "just work" without alot more effort to make things compatible with it. I could turn off DBContext generation, but then that moves having to deal with generating it instead.

I think you're right that a post-processing script might be the best alternative if there isn't a desire to add functionality to the splitting code for now.

[ErikEJ]

Wonder if the fact that it is set to null is a bug?

I think you're right that a post-processing script might be the best alternative if there isn't a desire to add functionality to the splitting code for now.

Cool!

[ErikEJ]

Wonder if the fact that it is set to null is a bug?

Looks like I am composing other namespaces using this, so it is probably by design

[jwyza-pi]

It's weird that the other 2 T4 template types are fine with it being null, but this one isn't.

[jwyza-pi]

Just for other folks who might want to do this in the future (until we have T4 template support for EntityTypeConfiguration). You'll need to update DbContext.t4 to set the class to internal (or update this script to change both the configs and the DbContext class). But then you can use this script (at least if you have powershell installed, which works on any OS these days):

# After a scaffolding event, we want to change the generated Entity Configurations from public to internal.
Param (
    [Parameter(HelpMessage="The path within the project where the models reside", Mandatory=$true)]
    [string] $ModelsPath,
    [Parameter()]
    [Switch]
    $DryRun
)

# Construct the path to the Models directory
$modelsPath = "${ModelsPath}"
$modelsConfigurationPath = "${modelsPath}\..\Configurations"

# Check if the Models directory exists
if (Test-Path -Path $modelsPath) {
 # Update the configuration files to be internal (Until EF Core Power Tools supports T4 Templates for EntityTypeConfiguration)
    $files = Get-ChildItem -Path $modelsConfigurationPath -Filter "*Configuration.cs" -File
    
    foreach ($file in $files) {
        Write-Host "Updating $($file) to be internal instead of public."
        (Get-Content $file) -replace 'public partial class', 'internal partial class' | Set-Content $file
    }
} else {
    Write-Host "The Models directory does not exist at the path: $modelsPath"
}

In my efpt.postrun.cmd, I call it like so:

./tools/Post-Scaffold.ps1 -ModelsPath Models