btw refunded your question credit.
Hello,
"Program" is not a C # reserved keyword and yet when you want to use an entity with this name as an association on another entity the Program.cs file is not listed. However, the creation of the "Program" entity went very well.
Erratum: It's only related on the filename "Program.cs" If I rename it to "ProgramTest.cs" all is working well.
Nicolas.
@willignicolas
yes it's not a C# reserved keyword but Suite automatic class finder filters it because it's interferring with program.cs in host projects.
Also it may break namespaces as there's an existing Program class.
I created an internal ticket for that to be able to use Program keyword.
I myself had the same situation while creating Program in a School portal. It's being problem with dotnet Program classes (not related to ABP) so I used SchoolProgram. But if you insist on this name, there's a work around. Choose any other class (eg: AppUser) then save it without generating. After, go to aspnet-core\.suite\entities folder and find your entity.json. You'll see the file paths and other properties for the navigation property. Update them and go back to Suite. Refresh it and click save and generate.
hi, looks like it's a configuration problem. maybe you configured it correct but didn't set environment or you didn't configure it well. let's see a sample Blazor appsettings.json configuration Ensure that these configuration are aligned with your server environment (production stating whatever)
HttpApi.Host > appsettings.json
{
"App": {
"SelfUrl": "https://host.abp.io",
"CorsOrigins": "https://blazor.abp.io"
},
"ConnectionStrings": {
"Default": "Server=localhost;Database=MyProject;Trusted_Connection=True;MultipleActiveResultSets=true"
},
"AuthServer": {
"Authority": "https://host.abp.io"
}
///////// other settings //////////
}
Blazor > appsettings.json
{
"AuthServer": {
"Authority": "https://host.abp.io",
"ClientId": "MyProject_Blazor",
"ResponseType": "code"
},
"RemoteServices": {
"Default": {
"BaseUrl": "https://host.abp.io"
}
}
}
Besides you cannot go live with the inital database seed. That's configured for your local dev environment (you can see localhost endpoints inside your Identity Server database tables)
Check the database tables with the prefix IdentityServer.
Especially these fields:
SELECT ClientId, PostLogoutRedirectUri FROM IdentityServerClientPostLogoutRedirectUris
SELECT ClientId, RedirectUri FROM IdentityServerClientRedirectUris
SELECT Id, ClientId, FrontChannelLogoutUri FROM IdentityServerClients
it's probably related to your Azure settings. because it's a native feature of dotnet core. ABP doesn't add anything on top of aspnet configuration feature.
I'm closing this question as the main question has been resolved. You can create a new question for your new question
According to the framework rules, you cannot disable the UnitOfwork pipeline.
The only reason to disable the UnitOfWork is managing the UnitOfWork on your own with IUnitOfWorkManager with the following code
using (var uow = _unitOfWorkManager.Begin(requiresNew: true, isTransactional: false ))
{
//.....
await uow.CompleteAsync();
}
You might want to disable transaction for the corresponding method. To do this basically add the following attribute
[UnitOfWork(isTransactional: false)]
If you really want to disable the UnitOfWork, you can use FindAsync() instead of FirstOrDefaultAsync()

Related document https://docs.abp.io/en/abp/latest/Unit-Of-Work
let us check it. subscribe the question to get email notification
@jackmcelhinney see => https://support.abp.io/QA/Questions/740/ObjectDisposedException-when-UnitOfWork-disable
thanks we got your solution. it's under investigation.