Activities of "Jorahealth"

Hi Team,

We have recently migrated our Angular project from Angular 10 to Angular 18, and we are considering adopting Standalone Components, Directives, and Pipes to simplify our project structure and improve performance.

However, we noticed that the Entity Creator does not seem to follow this approach. Before proceeding, we would like to understand: 1.Does ASP.NET Zero officially support Standalone Components in Angular 18? 2.Are there any compatibility concerns or known limitations with introducing angular best practice features in an ASP.NET Zero environment? 3. Are there any known issues or compatibility concerns with using Standalone Components in ASP.NET Zero projects? 4. If standalone was a necessary improvement, why hasn’t ASP.NET Zero adopted it in its templates yet? 5. Does ASP.NET Zero have any recommendations or guidelines on adopting Angular 18 best practices, especially features?

Additionally, I have a question regarding the versioning of our application. We have successfully migrated the backend server code to a newer version, and it shows as API: v13.3.0. However, the client version is still showing as Client: v9.2.0 [20250210], which seems to be the older version. Could you help us understand?

Your guidance will help us decide whether to implement this in our application. Looking forward to your response.

Many Thanks.

Hi, We have encountered an issue in our Angular application after updating to Angular 18 and the latest PrimeNG versions.

I've removed the return statement after paginator.changePage(0), ensuring the API call is made even when resetting pagination.

Removing return allows the API to be called after resetting the paginator, ensuring data is fetched and displayed correctly.

Does this approach align with best practices, and is it the recommended solution for resolving this issue? If not, do you suggest an alternative way to handle pagination resets and API invocation, please?

Many thanks.

Dear Support Team,

I am encountering an issue with the message section in my application. When I click on the message section, I expect to see all the mails displayed in the view. However, no mails are being displayed.

Observations: Upon inspecting the application, I noticed that the GetAll API responsible for fetching the messages is not being triggered. I placed a debugger in both: The front-end code where the GetAll API function is called. The back-end code of the corresponding function. However, neither of these debuggers is being hit, indicating the API is not being invoked at all. Request: Could you please guide me on potential reasons for this behaviour?

Are there any specific areas I should check in the front-end or back-end configuration that might cause the API not to trigger? I look forward for your response.

Many thanks.

Hi, I attempted to access the link you suggested, but unfortunately, it is redirecting to a 404 error message. To address the issue I’ve been experiencing with the permissions tree:

I upgraded my PrimeNG version from 17.18.5 to 18.0.2 and also updated the primeicons to the latest version. I searched for related tickets or documentation about similar PrimeNG issues but couldn’t find any relevant solutions. Despite these efforts, the issue persists. Could you kindly suggest further troubleshooting steps or direct me to the appropriate resources?

Hi,

Thank you for your response.

To address your queries:

Clarification of the Issue:

Yes, the issue is with the permission tree on the user interface. The tree lists the permissions and displays them correctly, but I am unable to select or add permissions in the Angular migrated code(Angular side Permissions functionality issue). This functionality works as expected in the new Angular base code.

PrimeNG Package Version:

The PrimeNG package version in my migrated code is "primeng": "^17.18.5".

Please let me know if there’s any additional information or context you need to help diagnose the issue.

Looking forward to your guidance. Many thanks.

Dear Support Team,

First of all, I would like to thank you for your prompt and helpful responses to my previous queries. Your guidance has been invaluable, and I truly appreciate the support you’ve provided so far.

I’m reaching out again regarding another issue with the permissions functionality in our application.

Issue Details: In the new Angular base code (v18), the functionality for adding permissions to users is working perfectly. However, in the migrated Angular code (v10 to v18), the same functionality does not work. I have not modified any of the related components or shared files during the migration and copied all relevant files from the new base code. I also compared the connected components in both versions, and there are no visible code differences.

Could you kindly suggest what might be causing this discrepancy? Are there any hidden dependencies or configurations that might affect this functionality in the migrated code?

I greatly value your assistance and look forward to your guidance in resolving this issue.

Many thanks.

Hi Support Team,

Thank you so much for your response.

We recently migrated our codebase from version 9.2.0 to 13.2.1, and we are now attempting to configure our old database with the new migrated code. However, we are encountering issues when running the migrator.

The primary challenge seems to be related to differences in the database schema:

The new version introduces additional columns, such as " RecoveryCode ", which are not present in the old database schema. This discrepancy appears to be causing errors during the migration process. Could you kindly advise on the best approach to use our old database with the new migrated code? Should we manually update the old database schema to align with the new codebase, or is there a recommended process for handling this situation?

Looking forward to your guidance.

Many thanks.

Dear Support Team,

Thank you for your detailed response and suggestion regarding the UnitOfWork process. The issue has been resolved successfully based on your guidance, and everything is now working as expected.

I have one follow-up question:

Is this solution a custom fix or workaround specific to our scenario? If not, could you clarify why this approach or guidance is not included in the base version by default? Your insight would be greatly appreciated.

Many Thanks.

Hi,

I have sent an email to support@aspnetzero.com with the project files attached, as requested. Please let me know if you require any additional details or further clarification.

Looking forward to your response.

Many Thanks.

Hi Support Team,

Additional Information: Upon further investigation, I found that the DbContext.cs file in the new codebase version (13.2.0) contains 134 lines of code. However, during migration, we pulled our old code with the DbContext.cs file from our old codebase, which has around 1400 lines of code, including all the entities.

Could this discrepancy in the DbContext.cs file be causing the GetDbContext() null issue mentioned earlier? If yes, could you advise on the best approach to resolve this? Should we retain the old code, or is it necessary to adapt to the new version's structure?

Many Thanks.