Activities of "dshapiro"

Thanks Liming, I think I see where my confusion was.

I was thinking of generate-proxy as only targeting the default app module, but I've been reminded that proxies can be generated for a specific module key (if listed in /api/abp/api-definition).

So if I understand correctly, the distributed modulecan remain structured normally, with its API surface exposed under its own module key. Then, on the React side, the consuming host would generate proxies for both its own app module and for my distributed module, unless we create our own convention for shipping/generated API clients inside our React npm package.

That answers my question. Thanks for clarifying.

Thank you, Liming!

Just to confirm I understood the proxy guidance correctly: historically, distributable modules were responsible for their own app services and proxy layer. The app services for the module would exist within their own module (per /api/abp/api-definition), and the Angular frontend package would ship with the appropriate proxies to communicate with that app service layer. In your React example, you mentioned that the host application, not the distributed module, would be responsible for generating the proxies. Does this mean that, for the modern React stack, the distributed module's app service layer should be exposed through the main application module? This could complicate things if we need to support both an Angular UI (where the app services and proxies are owned by the module) and a React UI (where the app services may need to be merged into the main app module).

Secondly, it is important for me to understand ABP’s direction before I commit my company to an approach. Can you confirm whether ABP’s new naming scheme — Angular = classic, React = modern — signals that ABP is committing to a shift away from Angular and toward a new React-based frontend? Or, with the pending Hybrid UI infrastructure, is ABP’s long-term direction more that UI modules should eventually be framework-neutral? If the latter, I would suggest reconsidering the classic/modern naming, since it implies an intended migration path from Angular to React.

The practical reason I’m asking is that we need to decide how to build reusable modules today. It would be useful to know whether the recommended path forward is Angular or React, or whether this is something we should wait on until the Hybrid UI spec is more clearly defined.

I'm awaiting a response from a human and hoping the AI response is based on limited documentation rather than the intended direction. The response as presented is disappointing.

Although my read may be incorrect, given the relabeling of React as "modern" and Angular as "classic", it seems reasonable to assume that React is intended to become the primary UI stack going forward. If that's the case, I would expect the React ecosystem to support a proper module integration model, including the ability to build and deliver self-contained modules with both backend and frontend pieces. ABP itself already does this with modules like Text Templating, CMS Kit, Identity, etc., so it would be surprising if custom modules could not follow a similar pattern. Expecting module consumers to build their own frontend for each reusable module feels like a significant limitation and weakens the value of ABP's modular architecture.

Additionally, the public React app / Admin Console split is a great direction and solves a real pain point. However, based on the current documentation and AI response, it seems like custom module management pages may need to be added to the public React app rather than contributed into the Admin Console. If that is accurate, I think that is a mistake. It is common to need both a public site and an admin site, and module-provided UI should be targetable to either the public or admin console as needed.

So the main question is: is the modern React UI intended to support true frontend modularity for custom modules? If yes, it would be helpful to understand the planned extension points. If no, that has significant implications for anyone building reusable ABP modules on the modern React stack.

We are building a reusable ABP module using ABP Framework 10.4 with the "modern" template (React + Admin Console). The module is structured as a distributable NuGet package and follows the standard DDD layer structure generated by abp new-module --modern.

We want to add a management section to the React admin console frontend. This UI needs to be distributable with the module itself so it can be consumed by any host that installs the module.

With the classic Angular template, abp new-module generated an Angular project inside the module structure. This gave a clear pattern for packaging and consuming module UI.

With the modern template (--modern), abp new-module creates no frontend project at all. We cannot find any guidance or tooling for how a module should contribute React UI.

Our questions:

1. Is there an official or recommended pattern for packaging React UI inside an ABP module so that a host React app can install and consume it?
2. Should the module ship a React npm package (alongside its NuGet packages) that the host imports? If so, what does the expected integration look like — does the module export components, TanStack Router route factories, or something else?
3. Is there an ABP-provided mechanism analogous to Angular's forRoot() or forChild() that lets a module register its routes and menu items into the host React app without the host having to implement any logic itself?
4. Is there a way to add our content to the admin console rather than the public site?
5. Are there any ABP commercial modules (e.g., Identity Pro, Payment, SaaS) whose React source we can reference as a concrete example of the expected pattern?

Any documentation, roadmap information, or example code would be very helpful.

I no longer have the logs, but I can tell you they did not. It went through a dotnet restore process, then exited with no further output. Not sure if relevant, but this is on ABP v9.x

We have file logging disabled - we prefer db logging. The db logs don't include any mention of needing to login. We also tried launching with dotnet run and saw no messages about why the application was aborting.

"Serilog": {
    "Using": [ "Serilog.Sinks.MSSqlServer", "Serilog.Sinks.Console" ],
    "MinimumLevel": {
        "Default": "Information",
        "Override": {
            "Microsoft": "Warning",
            "Microsoft.EntityFrameworkCore": "Warning",
            "System": "Warning"
        }
    },
    "Enrich": [ "FromLogContext", "WithMachineName" ],
    "Properties": {
        "Application": "Elite Tenants Platform"
    },
    "WriteTo": [
        {
            "Name": "MSSqlServer",
            "Args": {
                "connectionString": "Default",
                "sinkOptionsSection": {
                    "tableName": "Logs",
                    "autoCreateSqlTable": true
                },
                "restrictedToMinimumLevel": "Warning",
                "columnOptionsSection": {
                    "additionalColumns": [
                        {
                            "ColumnName": "MachineName",
                            "DataType": "varchar",
                            "DataLength": 50
                        },
                        {
                            "ColumnName": "UserId",
                            "DataType": "uniqueidentifier",
                            "NonClusteredIndex": true
                        }
                    ]
                }
            }
        }
    ]
},

This should not be logged as "Information", this should be thrown as a critical error if it's going to abort execution.

My sys admin and I wasted approximately two hours trying to diagnose and troubleshoot why ABP applications on my PC would not run. They would get to a certain point in the startup and then abort execution. I checked db logs and event viewer and nothing was present. We tried uninstalling Windows Updates, registry hacks, etc... no luck. Until I finally had the idea to try to run some abp cli commands and see what happens... that's when I finally received the message that my ABP account was not logged in.

This really needs better handling. Rather than silently failing on launch, there should be a clear AbpSessionException or more appropriate name with clear message: "You must login to your ABP account to run this application".

Gotcha! Thanks for your help on this!

Thank you. The example you provided got me what I needed. I removed the tenancy check (since we're not using multi-tenancy in our application) and ended up with this revised version (below).

A couple things I need:

1. The shared file and screenshot contain client-identifying information (namespaces in code, name in screenshot) and I ask you to please edit your post and remove those.
2. Can you help me understand why this edit is necessary? Since this is an override, I would expect the base class to already handle this.

protected override async Task TrySetEmailAsync()
    {
        if (IsExternalLogin)
        {
            var externalLoginInfo = await SignInManager.GetExternalLoginInfoAsync();
            if (externalLoginInfo == null)
            {
                return;
            }

            if (!externalLoginInfo.Principal.Identities.Any())
            {
                return;
            }

            var identity = externalLoginInfo.Principal.Identities.First();
            var emailClaim = identity.FindFirst(AbpClaimTypes.Email) ?? identity.FindFirst(ClaimTypes.Email);
            var givenNameClaim = identity.FindFirst(AbpClaimTypes.Name) ?? identity.FindFirst(ClaimTypes.GivenName);
            var surnameClaim = identity.FindFirst(AbpClaimTypes.SurName) ?? identity.FindFirst(ClaimTypes.Surname);

            if (emailClaim == null)
            {
                return;
            }

            var userName = await UserManager.GetUserNameFromEmailAsync(emailClaim.Value);
            Input = new PostInput
            {
                EmailAddress = emailClaim.Value,
                FirstName = givenNameClaim?.Value ?? "",
                LastName = surnameClaim?.Value ?? "",
            };
        }
    }