Activities of "rshapiro"

EntityChangeWithUsernameDto is not a custom Dto it's an ABP DTO that's part of the audit logging namespace and is the return from IAuditLogsAppService.GetEntityChangesWithUsernameAsync.

Yes, I know it's a bug but just wanted to make sure you're aware of the issue and can provide a permanent fix so that future ABP updates don't override my manual fix

Environment ABP Framework: 10.6.0 UI: Angular @abp/ng.core: 10.6.0 @abp/ng.schematics: 10.6.0 @volo/abp.ng.audit-logging: 10.6.0 ABP Studio CLI: 3.1.3 Operating system: Windows

Description: I implemented a custom application service endpoint that returns entity change history as: Task<List<EntityChangeWithUsernameDto>>

After generating Angular proxies, the generated EntityChangeWithUsernameDto references EntityChangeDto, but the generated file neither declares nor imports that type. Angular compilation fails with: Cannot find name 'EntityChangeDto'.

There also appears to be a related issue in the generated Audit Logging service: package-provided DTOs are imported from the local generated models file instead of @volo/abp.ng.audit-logging/proxy.

The response to /api/abp/api-definition?includeTypes=true includes contains a complete EntityChangeDto in the types section, including its base type and property definitions.

With the help of ChatGPT I found two problems in @abp/ng.schematics:

1. VOLO_PACKAGE_PROXY_IMPORTS maps EntityChangeDto and other Audit Logging DTOs to @volo/abp.ng.audit-logging/proxy, so those DTOs are intentionally excluded from local model generation. However, the model import logic skips a referenced type when it shares the model’s C# namespace. This leaves EntityChangeWithUsernameDto without the necessary package import.

2. The shared createTypeToImportMapper does not apply VOLO_PACKAGE_PROXY_IMPORTS when constructing imports. The model-generation path subsequently applies package resolution, but the service-generation path does not perform that same step.

Made local fixes to utils/model.js and utils/type.js to work around the issue but will need a permanent fix.

This issue is similar to issues #20680 and #20741

Thanks for the help. Had already fixed things manually before my last response. Was just letting you know there is that issue.

Hi,

Yes, the packages are centrally managed. I did this based on your suggestion, after the 10.4 update, to resolve the issues of the vulnerabilites being reported by Scriban and AutoMapper. I've shared the files you requested below.

Directory.Packages.props Whitecap.COE.HttpApi.Host.csproj

Thanks that worked now. One thing I noticed though is that the update changed all the versions for every package in the abpmdl and abpsln to unknown. Now if I try to run the update again it throws an exception indicating that package was not found

I've tried several of the suggestions with no luck. More and more I'm thinking that the fact that I'm stuck on v5.1.1 of LeptonX is the issue because it's pretty old. Not sure how I get it to update

Trying to update my solution from v10.4 to 10.5 and getting the following exception:

NuGet package not found Package: Volo.Abp.LeptonXTheme.Installer, Version: 5.1.1 Volo.Abp.Studio.AbpStudioException: Exception of type 'Volo.Abp.Studio.AbpStudioException' was thrown. at async Task Volo.Abp.Studio.Nuget.NugetPackageManager.DownloadAsync(string packageId, string version, bool useOnlyPublicNuGet) at async Task<string> Volo.Abp.Studio.Nuget.NugetSourceCodeStore.GetContentsPathAsync(string packageId, string version) at async Task<string> Volo.Abp.Studio.Modules.Installing.RemoteModuleManager.tAnjdU27gp(string , string ) at async Task<ModuleInfo> Volo.Abp.Studio.Modules.Installing.RemoteModuleManager.EGmjGKjGCi(string , string version) at async Task<ModuleInfo> Volo.Abp.Studio.Modules.Installing.RemoteModuleManager.GetModuleInfoAsync(string referenceModule, string version) at async Task Volo.Abp.Studio.Modules.ModuleManager.AdjustImportVersionsAsync(string modulePath) at async Task Volo.Abp.Studio.Cli.Commands.StudioUpdateCommand.ExecuteAsync(CommandLineArgs commandLineArgs) at async Task Volo.Abp.Studio.Cli.StudioCliService.RunInternalAsync(CommandLineArgs commandLineArgs) at async Task Volo.Abp.Studio.Cli.StudioCliService.RunAsync(string[] args)

The update process then just exits. Attempting the update again just throws the same exception and exits. I can see from the nuget source for that package, the last release was 5.4.1 so not certain why it's trying to download such an old version.

Any help would be appreciated.

Thanks,

Thanks @maliming will take a look at the AutoMapper options you provided. However, even the 7.0 version of Scriban has security vulnerabilities see https://github.com/advisories/GHSA-24c8-4792-22hx

AI answer doesn't help as this is not two separate issues. Vulnerable nuget packages -> EF Migration / DB updates headache. The v10.5 roadmap says 3rd party updates just want to know if updating these packages is in that.

Will you be updating the versions of the AutoMapper and Scriban nuget packages any time soon? The versions currently being used have been reporting vulnerabilities for quite some time. Also, VS 2026 now forces EF migration generation and DB update processes to stop regardless of what the ErrorActionPreference is set to.