Activities of "EngincanV"

Hi, you're right, version selection is currently missing in the new ABP Studio CLI and Studio GUI. The team is aware of this and plans to prioritize bringing it back (there is an internal issue to support that asap). Thanks for your understanding.

As a workaround, you can use the old CLI and specify a version using the --old flag:

abp new YourProjectName --version <version> --old

Note that this uses ABP's old templating system, not the current ABP Studio templates.

Regards.

Hi, in the GetWaitingEventsAsync method, a new optional parameter was added, and your problem seems to related to package version inconsistency. I know you've already cleaned your solution, rebuilt it, and checked the .dll files, but it looks like one of your .csproj files may have an incorrect package version.

Could you please check your .csproj files and confirm that all package versions are correct?

I use a Directory.Packages.props file to manage all NuGet package versions, and I’ve confirmed that every ABP-related package is set to version 9.0.4.

Okay, thanks for confirming. Interestingly, it throws a System.TypeLoadException, which suggests that the method's signature has changed. It looks like one of your NuGet packages is referencing an older version of ABP's EventBus package.

To assist you better, could you share your solution via email (support@abp.io) along with the ticket number? This will allow me to check it directly in your application and help resolve the issue.

Hi, the package Volo.Abp.Studio.Extensions.StandardSolutionTemplates is used by ABP CLI and ABP Studio to provide solution templates. Are you trying to install it manually? It's recommended to let ABP Studio CLI or GUI handle the installation for you. (This is not a package that can be used in your own applications)

Hi, https://abp.io/support/questions/8763/Issue-Creating-Proxies-8665#answer-3a18255f-5677-e4bf-a992-db36d7ae7d9c can you check this answer to see if it fixes your problem?

Thanks, we will try to implement this.
How the "AddOpenIdConnect" part should go in this case, where the configuration is defined dynamically? Here is a general example how that normally goes.

        context.Services.AddAuthentication() 
            .AddOpenIdConnect("ABP2AzureADScheme", "Logon with Azure AD", options => 
            { 
                 
                options.Authority = configuration["AzureAd:Instance"] + configuration["AzureAd:TenantId"] + "/v2.0/"; 
                options.ClientId = configuration["AzureAd:ClientId"]; 
                options.ResponseType = OpenIdConnectResponseType.CodeIdToken; 
                options.CallbackPath = configuration["AzureAd:CallbackPath"]; 
                options.ClientSecret = configuration["AzureAd:ClientSecret"]; 
                options.RequireHttpsMetadata = false; 
                options.SaveTokens = true; 
                options.GetClaimsFromUserInfoEndpoint = true; 
                options.Scope.Add("email"); 
 
                options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub"); 
 
            }); 

Hi, actually this part can stay exactly like this. Since you will implement the IConfigureOptions<> it will update the configuration dynamically.

It didn't work. I believe the issue is not related to the EF type, as the migration already has the correct SQL type. It seems to be caused by a deserialization or mapping step in the pipeline. Since extra property values are stored as Object, it could be a boxing issue. When replacing IdentityUserAppService, I noticed that the BirthDate property is stored as DateTime instead of DateOnly. Additionally, the response includes a time part, which suggests unintended type conversion. Request:

{ 
 "extraProperties": { 
   "NationalIdentityNumber": "12345678901", 
   "BirthDate": "2001-03-27" <--- no time 
 }, 
 "userName": "test", 
 "name": "test", 
 "surname": "test", 
 "password": "test123", 
 "email": "test@test", 
 "phoneNumber": "", 
 "isActive": true, 
 "lockoutEnabled": true, 
 "emailConfirmed": false, 
 "phoneNumberConfirmed": false, 
 "shouldChangePasswordOnNextLogin": false, 
 "roleNames": [], 
 "organizationUnitIds": [] 
} 

Response:

{ 
    "tenantId": null, 
    "userName": "test", 
    "email": "test@test", 
    "name": "test", 
    "surname": "test", 
    "emailConfirmed": false, 
    "phoneNumber": "", 
    "phoneNumberConfirmed": false, 
    "supportTwoFactor": false, 
    "twoFactorEnabled": false, 
    "isActive": true, 
    "lockoutEnabled": true, 
    "isLockedOut": false, 
    "lockoutEnd": null, 
    "shouldChangePasswordOnNextLogin": false, 
    "concurrencyStamp": "6d0c02c007114cfa8a6eb816bd9f277c", 
    "roleNames": null, 
    "accessFailedCount": 0, 
    "lastPasswordChangeTime": "2025-03-27T07:16:52.8335677+00:00", 
    "isExternal": false, 
    "isDeleted": false, 
    "deleterId": null, 
    "deletionTime": null, 
    "lastModificationTime": null, 
    "lastModifierId": null, 
    "creationTime": "2025-03-27T09:16:52.8579278+02:00", 
    "creatorId": "519c6b51-3e6f-8cb8-cade-3a17de0dafb7", 
    "id": "51e457a2-1a1e-5930-a2d4-3a18e8a2d980", 
    "extraProperties": { 
        "BirthDate": "2001-03-27T00:00:00", <---- time added 
        "NationalIdentityNumber": "12345678901" 
    } 
} 

This is how I see the problem:

1. Incorrect type casting in the pipeline.
2. The date is not saved in the database due to the wrong type, but no error is thrown; instead, a default value is set.
3. The response includes the user’s input, but time is added to date.

Btw, on UI date input is a simple text input, not a date picker.

Okay. I've reproduced the problem and it's exactly how you described it. I've created an issue for that: https://github.com/abpframework/abp/issues/22472

I'm refunding your ticket. Thanks for reporting the problem and your prompt explanation.

Regards.

Hi, EngincanV I did build. See my Step 4. Graph build. OK I can not add new Entity to [DemoSolution2] using ABP Suite. After adding it gives me error and I can not build using graph due to errors in module. So you did not answer my quition: why my module [NewModule] is impacted if I am adding entity into [DemoSolution2]?

I will share solution soon.

Thanks. I got your email, and will check the problem.

Hi, your finding that removing await allows the event to be published immediately when onUnitOfWorkComplete is false seems to be the correct workaround. Because, since you are not using the await keyword, it works like a sync method. But just notice, when you do that in an unhandled exception occurs then you are on your own in exception handling.

Second issue, after event published, even event handler method is virtual still it is not working correctly without using _unitOfWorkManager as below. Without using _unitOfWorkManager, child entities is not commiting to the db.

By using _unitOfWorkManager.Begin(requiresNew: true, isTransactional: true), you are explicitly creating a new and independent unit of work for the duration of your event handler's execution. This ensures that all operations within this using block, including changes to child entities, are tracked by EF Core within this specific unit of work.

Actually, since you are using the [UnitOfWork] attribute, normally it should work seamlessly but it's possible that the event handler is being invoked in a context where the ambient unit of work has already been completed or disposed, or perhaps the event handling mechanism in this specific scenario doesn't correctly hook into the ambient unit of work management for child entities. I'll check this.

Regards.

Hi, in the GetWaitingEventsAsync method, a new optional parameter was added, and your problem seems to related to package version inconsistency. I know you've already cleaned your solution, rebuilt it, and checked the .dll files, but it looks like one of your .csproj files may have an incorrect package version.

Could you please check your .csproj files and confirm that all package versions are correct?

Hi, thanks for the detailed information. Your code for extending the IdentityUser with a DateOnly property for BirthDate looks correct at first glance. ABP's entity extension mechanism should handle this. However, the fact that the property always defaults to 0001-01-01 suggests that the value is indeed not being set during user creation.

Your suspicion about type casting is likely on the right track. You can try to explicitly configure column type in mapping as follows:

ObjectExtensionManager.Instance.MapEfCoreProperty<IdentityUser, DateOnly>(
                UserExtraPropertyNames.BirthDate,
                (_, propertyBuilder) =>
                {
                    propertyBuilder.IsRequired();
                    propertyBuilder.HasColumnType("date");
                });

By explicitly setting the column type (propertyBuilder.HasColumnType("date")), I think your problem should be resolved. Can you try it and let me know if it fixes, please?