Hi, We would need your assistance on a problem we have with an implementation in order to adapt your architecture to our need. In particular we wanted to know if there is the possibility that you could create a library or branch in which the id key (PK Key) for the Identity tables (.net core) are Integers (or String/Gui) instead of BigInt (Int32 instead of Int64). The ideal would be (as the identity core engine already allows) to be able to have a functionaly of AspNetZero the allows to inject through Dependency Injection the needed type TKey from elsewhere. We have read in your documentation that it is not possible. To make you understand better our use-case, see below the tables of our solution and the ones of AspNetZero. Our objective would be to abandon ours to use the ones from your boilerplate.
<br>
| Our Tables | KeyType | Asp.net Zero Tables | KeyType |
| ---------- | ------- | ------------------- | ------- |
| Users | Id(Pk) nvarchar(450) | AbpUsers | Id(Pk) BigInt |
| UserLogins | UserId(Pk) nvarchar(450) | AbpUserLogins | Id(Pk) BigInt |
| UserClaims | "<b>Id(Pk) Int</b>" - UserId (Fk) nvarchar(450) | AbpUserClaims | "Id(Pk) BigInt" - UserId (Fk) BigInt` |
| UserTokens | UserId (Pk Fk) nvarchar(450) | AbpUserTokens | Id(Pk) BigInt - UserId (Fk) BigInt |
| Roles | Id(Pk) nvarchar(450) | AbpRoles | Id(Pk) Int |
| RoleClaims | Id(Pk) Int RoleId (Fk) nvarchar(450) | AbpRoleClaims | Id(Pk) BigInt RoleId (Fk) Int |
| UserRoles | UserId(Pk) nvarchar(450) - RoleId nvarchar(450) | AbpUserRoles | Id(Pk) BigInt - UserId (Fk) – BigInt RoleId Int |
We managed to adapt our solution and link your tables using a functionality of overwriting the type string with a TKey of type long (for your Role table that uses an Int we used the convert function of the build model). All goes well except for the table AbpUserClaims for which you use BigInt as id... This also gives us an error in the call to the native library Microsoft.AspNetCore.Identity.PasswordSignInAsync of our project that breaks internally when we make use of the generic type TUser because AbpUserClaims has BigInt as id.
Everything would be resolved if your solution would have Int instead of BigInt as id of the table AbpUserClaims.
If an evolution is too much, do you have any idea of a workaround? Thank you.