Need more documentation on this tag: https://commercial.abp.io/releases/pr/14629
We are currently preparing the documentation.
Hi, thanks for the feature request. I will create an internal issue for that. But please notice that this can not be included in the 7.4 release because we need to first consider making these changes or not. So, we will examine this feature request and try to prioritize it. Thanks for your understanding.
BTW, your credit is refunded.
Best Regards.
Why is not that solution included in 7.4? In my opinion, the fix of EfCoreRepository, it's critical because it can lead to data issues right now. Is it possible to include at least the EfCoreRepository fix only or a temporary workaround?
We aimed to enable nullable annotations for all our projects in v8.0 (https://github.com/abpframework/abp/issues/16610), therefore we have made the related changes on the dev
branch and because of that all of those changes will be included in v8.0 and unfortunately, it's not possible for us to include this change in the 7.4 release.
There is another issue in the generated EfCoreEntityRepository.cs class
The issue corresponds to the **FindAsync **method inside the **EfCoreRepository ** class
There seems to be a problem between the nullable-enabled project and the non-enabled nullable project (EntityFramework Project).
One method returns a nullable type while the other expects a non-nullable return value.This is a critical error for the new version.
3>EfCoreUbigeoRepository.cs(14,106): Error CS8613 : Nullability of reference types of the return type of "Task<Ubigeo> EfCoreRepository<DemoDbContext, Ubigeo>.FindAsync(Expression<Func<Ubigeo, bool>> predicate, bool includeDetails = true, CancellationToken cancellationToken = default(CancellationToken))" does not match member "Task<Ubigeo?> IRepository<Ubigeo>.FindAsync(Expression<Func<Ubigeo, bool>> predicate, bool includeDetails = true, CancellationToken cancellationToken = default(CancellationToken))" implemented implicitly. 3>EfCoreUbigeoRepository.cs(14,106): Error CS8613 : Nullability of reference types of the return type of "Task<Ubigeo> EfCoreRepository<DemoDbContext, Ubigeo, Guid>.FindAsync(Guid id, bool includeDetails = true, CancellationToken cancellationToken = default(CancellationToken))" does not match the implicitly implemented member "Task<Ubigeo?> IReadOnlyBasicRepository<Ubigeo, Guid>.FindAsync(Guid id, bool includeDetails = true, CancellationToken cancellationToken = default(CancellationToken))". 3>------- Finished building project: D.EntitemoyFrameworkCore. Succeeded: False. Errors: 2. Warnings: 0
The solution for this is the following.
In **EfCoreRepository.cs **
Replace this code:
public async override Task<TEntity> FindAsync( Expression<Func<TEntity, bool>> predicate, bool includeDetails = true, CancellationToken cancellationToken = default) { return includeDetails ? await (await WithDetailsAsync()) .Where(predicate) .SingleOrDefaultAsync(GetCancellationToken(cancellationToken)) : await (await GetDbSetAsync()) .Where(predicate) .SingleOrDefaultAsync(GetCancellationToken(cancellationToken)); }
For this
public async override Task<TEntity?> FindAsync( Expression<Func<TEntity, bool>> predicate, bool includeDetails = true, CancellationToken cancellationToken = default) { return includeDetails ? await (await WithDetailsAsync()) .Where(predicate) .SingleOrDefaultAsync(GetCancellationToken(cancellationToken)) : await (await GetDbSetAsync()) .Where(predicate) .SingleOrDefaultAsync(GetCancellationToken(cancellationToken)); }
And replace this code:
public virtual async Task<TEntity> FindAsync(TKey id, bool includeDetails = true, CancellationToken cancellationToken = default) { return includeDetails ? await (await WithDetailsAsync()).OrderBy(e => e.Id).FirstOrDefaultAsync(e => e.Id.Equals(id), GetCancellationToken(cancellationToken)) : await (await GetDbSetAsync()).FindAsync(new object[] { id }, GetCancellationToken(cancellationToken)); }
For this one
public virtual async Task<TEntity?> FindAsync(TKey id, bool includeDetails = true, CancellationToken cancellationToken = default)
{
return includeDetails
? await (await WithDetailsAsync()).OrderBy(e => e.Id).FirstOrDefaultAsync(e => e.Id.Equals(id), GetCancellationToken(cancellationToken))
: await (await GetDbSetAsync()).FindAsync(new object[] { id }, GetCancellationToken(cancellationToken));
}Hi,
Is there any news about this issue?
Thanks!
Hi Rafael, thanks for reporting. We have already fixed this (see https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.EntityFrameworkCore/Volo/Abp/Domain/Repositories/EntityFrameworkCore/EfCoreRepository.cs#L304) and enabled nullable annotations for all projects of both ABP Framework & ABP Commercial (https://github.com/abpframework/abp/issues/16610) and it will be available in v8.0.
There seems to be a bug when adding navigation collections (n:n) via Suite. In my case, I'm adding a navigation to a 'Tool' entity from 'ToolAssemblies' and get the following errors:
Edit: I should note this only occurs when using the 'Customizable code' option during crud page generation.
Error CS7036 There is no argument given that corresponds to the required parameter 'toolRepository' of 'ToolAssemblyManagerBase.ToolAssemblyManagerBase(IToolAssemblyRepository, IRepository<Tool, Guid>)' ToolAssemblyManager.Extended.cs
Error CS7036 There is no argument given that corresponds to the required parameter 'toolRepository' of 'ToolAssembliesAppServiceBase.ToolAssembliesAppServiceBase(IToolAssemblyRepository, ToolAssemblyManager, IDistributedCache<ToolAssemblyExcelDownloadTokenCacheItem, string>, IRepository<Tool, Guid>)' ToolAssembliesAppService.Extended.cs
Thanks for reporting. Whenever a many-to-many relation is established, it seems we also need to re-generate the ctor for the custom manager and appservice classes. I will create an issue for it and will fix it asap.
Last bug on my list for now, When you update a project from 7.3.2 to 7.3.3 via ABP Suite, it updates the Lepton theme to the preview build (3. instead of 2.3.3), which breaks it. (along with a few other packages, but this is the big one)
Not an issue if you manually downgrade from prereleases to stables it works fine, but the automatic process is supposed to stop this manual requirement :D
Thanks for reporting. We have already fixed this problem: https://github.com/abpframework/abp/pull/17344
Hi, this file is being created/updated automatically by the dotnet-ef CLI whenever a new migration is added.
The problem that you are facing with this file is not related to ABP & ABP Suite because we are not making any changes to this file, we are just running the related dotnet-ef command (dotnet ef add migrations <migration-name>
) under the hood to create a new migration.
Hi @SuperBeastX3, I will check and write back to you asap.