Hi,
You can try to update to 7.0.3, maybe it has been fixed.
Sorry. We are not ready to invest time into another update. Do you have other suggestions? Can you confirm this issue or suggest the way to resolve this issue in the existing solution 7.0.1?
I was unable to find "Bugs & Issues v7.0.1" (this is the version the bug below is reproduced), we are not planning to update to 7.2.x for the moment, but we need "Identity Server" section working ASAP.
SO...
After upgrading from ABP 5.1.2 to 7.0.1 I cannot add a claim to "Owned" When I'm trying to move any claim from right to left:
I am getting JS exception (because the given property is "undefined"):
The same goes for Identity Resources (and maybe other sections like this).
FYI: we keep using Identity Server, not Open ID Dict - probably it has something to do with this.
7.0.1
Angular
EF Core (Default)
Separate Auth Server
Windows (Default)
We love the framework but support and bug reporting is not handled well. My developer has mostly given up reporting issues as he says it's not worth it as responses tend to be one line, minimum effort answers. Complex issues often just get auto-closed without resolution.
I don't mind the one line answers but they should not be considered a paid response to an issue when we only get to report 15 a year. Basic forum responses should not be included in any limit.
Fully agree. I also noticed that the quality of the support has deteriorated: 2-3 year ago the replies (from the same support team members, BTW) were more meaningful, detailed and looked like a "ready-to-help" dialog. Now it looks like the total amount of work on the growing framework has noticeably increased since then and the support team simply does not manage to handle the support tickets. Well - it's the most careful explanation I have.
Mosf of the time - when we have a technical question - we are asked to either send the project source code or create the test version where the problem is reproduced.
The first one is not possible because of commercial nature of the project. The second one is very time consuming and is not possible too.
Yes, our solution is quite complex and we have some custom code on the top of ABP framework. But it would be great, if your support team devoted more time trying to understand the nature of the problem and analyze the fragments of the code shown in the message. Because often the answers are very short and meaningless - so we end up debugging out solution and looking at the downloaded ABP module source codes to resolve the problem ourselves.
p.ClrType == typeof(ExtraPropertyDictionary)
That was it. I was checking against string type only, would not expect such ClrType. Seems like I finally got rid of NVARCHAR. Thank you. I will keep this ticket open for some time until the migration is done...
And again you don't understand what I'm trying to say. I'm telling you that migration using a standard driver causes problem now. I have shown you the fragments of the code. Migration with Devart which has always been used never caused the problem. But now Devart cannot be used, they delay the NET7 support for month or so. You have published ABP7, but rely on Devart. Can you offer a working migration solution NOW?
Ok. But that was not my main question. My main question is why output generated by Devart differs from the standard one? They are supposed to be identical. Are you saying that output generated by standard driver is incorrect and cannot be used for Oracle migration??
Unfortunately, we don't have time and need to migrate now. So we need to use a generic Oracle driver.
The script which is generated by the generic driver, looks weird, though - it suggests to replace VARCHAR fields in ABP tables with NVARCHAR. There are a lot of such changes. Could you please explain, why in a 7.0.1 test app you are suggesting to use NVARCHAR/NVARCHAR2 DB type:
but at the same time the suggested Devart-based DB configuration has the following options, i.e. the DB fields are generated as VARCHAR/VARCHAR2?
So currently the generated migration script has tons of suggested changes like this (it compares the previously created migration using Devart and a generic dviver generation now):
I've tried to get rid of NVARCHAR manually in the DB migration context:
protected override void OnModelCreating(ModelBuilder builder)
{
//var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
//config.Workarounds.DisableQuoting = true;
//config.CodeFirstOptions.UseNonLobStrings = true;
//config.CodeFirstOptions.UseNonUnicodeStrings = true;
base.OnModelCreating(builder);
/* Include modules to your migration db context */
builder.ConfigurePermissionManagement();
builder.ConfigureSettingManagement();
builder.ConfigureBackgroundJobs();
builder.ConfigureAuditLogging();
builder.ConfigureIdentityPro();
builder.ConfigureIdentityServer();
builder.ConfigureFeatureManagement();
builder.ConfigureLanguageManagement();
builder.ConfigureTextTemplateManagement();
builder.ConfigureBlobStoring();
builder.ConfigureSaas();
foreach (var property in builder.Model.GetEntityTypes().SelectMany(e => e.GetProperties()).Where(p => p.ClrType == typeof(string)))
{
property.SetIsUnicode(false);
}
}
But it still generates me migration script with NVARCHAR/NVARCHAR2...
This does not help either:
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
configurationBuilder.DefaultTypeMapping<string>().IsUnicode(false);
}
hi
I think there is no problem with this.
Restore my question points then please if not done yet.
Eventually I've resolved thie issue. I've split the shared project DbContexts into 2 - one contains the entities which are shared in the consuming project, another one contains the entities which use the same table as the entities in the consuming project. Please, replenish my point for this question.