I see that most of the comments are abstract.
To fine-tune our documentation and get started steps, we need concrete examples.
Because for me it's very straightforward to kick-start a project.
Imagine that you start a new scratch ASP.NET Core project with Docker, DevExpress, and Identity Server with a tiered architecture, would it be slaphappy?
You asked for input on ways the support could be improved, and your responses say that you don't want to hear it.
Try to create a new solution with version 7.0.2 or 7.1.0 preview - app-pro, tiered, maui-blazor, PWA, separate identity server, and PostgreSQL. It doesn't run. You can't see the error because the screen is white and the text is white. It isn't immediately obvious if the program is hanging, or crashing, or not even starting. Once you change the text color the error just says an exception occurred in the Initialize function of one of the base ABP classes, which is not something you can debug unless you have full source code. The only way to find a more specific exception was to step through every single line of code. This is not "slaphappy".
You are selling a product that is supposed to allow the users to NOT have to become experts on all of the awesome features you have coded, but your documentation and tips for getting started are written from the perspective of people who ARE experts in all of those areas, and are expecting the audience to have a similar level of knowledge as well. I think you will have a much better chance of success with new perspective customers if you take the time to understand what things can go wrong for first time users, and provide some guidance on what a user needs to understand if they are going to deviate from the "out of the box" experience. We are very happy we are using ABP, but we had a LOT of frustration getting our solution off the ground, and we still get frustrating responses many times from support. Multiple DETAILED tickets where the response is effectively "RTFM". One was "You can't use DevExpress with a tiered solution". REALLY? We aren't expecting ABP to hand us fully functional solutions when we are doing custom integrations, but we do expect help understanding how to respect the benefits of ABP and still do what our business requires.
The framework is great, but the support frequently leaves us frustrated.
That does not answer the question at all. It is VERY frustrating that each time we open a ticket, the first response is to link to some generic documentation page. Did you actually read the question?
According to Microsoft documentation, System.Net.Mail.SmtpClient is obsolete and should not be used.
Additionally, Office 365 is going to disable basic authentication for SMTP as of December 31, 2022. https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online
All of the documentation indicates that MailKit https://github.com/jstedfast/MailKit is now the recommended solution.
I did not see a way to use OAuth2 with MailKit using the ABP module. Is there any sample code that demonstrates how to do this?
You keep avoiding answering my direct question.
We cannot implement any .NET classes because the legacy application is not written by us, it is a 3rd party C++ application which is writing directly to the database.
We have no problems using Auditing within ABP. We are looking to populate the audit log tables for changes made OUTSIDE of ABP in our legacy application (which does direct SQL queries, and cannot be modified to use the ABP APIs). Is there a documented approach? If not, is there a specific class we can look at to determine how best to emulate the logic? We have a subscription that includes full source code.
We are slowly replacing the UI for a very large existing application with ABP, and are happy to have the Auditing capabilities. Some entities may be completely controlled (created, updated, and deleted) by the legacy application for quite a while as we work on building out different areas using ABP. We would like to enable Audit Logging for changes to certain tables that are NOT being modified through ABP (although they will be in the same database as the ABP tables). Do you have any suggestions on how to write the appropriate audit log entries for changes made outside of ABP? The legacy application will be doing direct SQL edits, so we are thinking of tracking those changes using triggers.
As an example: When publishing our solution in Docker containers we had to establish routable URLs for the reverse proxy. This meant that https://www.somedomain.com/swagger and https://www.somedomain.com/api were routed to the Http-API container, https://www.somedomain.com/MVC was routed to the Web container, https://www.somedomain.com/Account , https://www.somedomain.com/connect , and https://www.somedomain.com/.well-known are routed to the Identity container, and everything else goes to Web.Public. The login process was working, but any pages requiring authorization would fail. The "Audit Logs" page, for example, would get an error on the call to https://www.somedomain.com/api/audit-logging/audit-logs?startTime=2021-11-02&endTime=&url=&userName=&applicationName=&correlationId=&httpMethod=&httpStatusCode=&maxExecutionDuration=&minExecutionDuration=&hasException=&sorting=executionTime%20desc&skipCount=0&maxResultCount=10 even though we could execute the same URL from the Swagger page without an error. Once I realized that I could not just copy/paste the "Request URL" from the Headers (when viewing the Developer Tools in the browser), I tried adding the additional /MVC/ in the path and it worked. Once I modified the abp.js file to set abp.appPath to include this as part of the base URL everything worked.
It appears that the problem was because the HTTP-API server cannot handle most of the API calls from the MVC client directly - when these calls were routed through the MVC client they all succeeded. It looks like the reason it worked from the Swagger interface is that the Swagger interface passed a JWT token which was not used on the MVC client. Once we determined that the API calls worked properly when the MVC subfolder/virtual directory was inserted, then it became obvious that the problem was due to "abp.appPath" not returning the correct base path.
Is there any documentation you can refer us to?
Containerized deployment is pretty common, and we really don't need the added complexity of going full microservices.
Is there someone who is familiar we can consult?
Is there an alternate way to configure the 4 containers behind a load balancer? The subfolders aren't mandatory if there is a different way to setup the routing rules (we need to know which requests go to Public, Web, API, and Identity).