Thank you for your followup. I will await documentation. Meanwhile, I will also wxplore templates as well.
Thanks for understanding. Regards.
Hi, we are providing some hook points, and even if you change those placeholders' locations the next time that you generate it will move them to the related places in the template. You can update the template and change the location of the placeholders if you want to put them in a different line.
So, yes they are being waited in certain points for now, but it's possible to change their places by updating the related custom code templates.
We will prepare a documentation to describe the custom code support asap. Thanks for your understanding.
Regards.
the tag <suite-custom-code-block-1>...</suite-custom-code-block-1> is never generated when I choose to generate the page without creating a new entity in the database. This is an existing project upgraded to the 7.4 rc-4. I am trying to get the suite-custom-code-block-# tags to generate in the existing page, which does get regenerated. However, the custom code block tags are not created in the page. If I create a new entity, the suite-custom-code-block-# tag comments are sprinkled throughout the .cshtml page. seems to be ignored when I regenerate code wrapped in this tag in a .cshtml page. I have checked the customizable checkbox in ABP Suite. The .cshtml page is recreated completely, wiping out any change wrapped in the custom code block tags for existing pages that I manually add these tags to, since APB SUITE does not add them when regenerated.
Hi, I have re-checked it again and it seems there is not any problem here. You should have added the code block as follows:
Correct ✅
@*//<suite-custom-code-block-1>*@
<h1>customizated content</h1>
@*//</suite-custom-code-block-1>*@
Wrong ❌
@*<suite-custom-code-block-1>*@
<h1>Custom Code</h1>
@*</suite-custom-code-block-1>*@
Our placeholder is //<suite-custom-code-block-n>
, please try with this placeholder and you will see that it's working as expected.
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