NewLife.Cube: from an entity class to a working admin panel

The premise: a table should become an admin interface

NewLife.Cube describes itself as a rapid web development platform for data-driven, fast iteration and deep customization scenarios. The mechanism is stated in one sentence and it is the whole product: in minutes, an entity class or database table becomes a complete admin UI with permissions, lists, details, CRUD, export and statistics, while standard APIs are exposed for Vue, Blazor, Antd, mobile or third-party systems.

So the problem it solves is not how to build an admin panel. That is well understood. The problem is how to build ten of them, or a hundred, without writing a screen per table and a permission list per screen. The answer is convention over configuration: an entity class and a controller are enough for the scaffolding to appear.

The features table in the README makes the shape concrete. EntityController scaffolding gives an entity class plus a controller immediate CRUD, statistics, export and permissions, with ReadOnlyEntityController covering read-only lists, and static-constructor configuration used for the setup. The repositories make the ecosystem visible: separate packages for Vue, Blazor, Angular, ElementUI, ArcoVue, MUI, Metronic, Metronic8, Tabler, NaiveUI, Shadcn, Svelte, TDesign, Vuetify, LayuiAdmin, AdminLTE and Swagger, each of them a front-end theme or integration rather than a different backend.

The primary language being JavaScript reflects where the bulk of the code sits, since those front ends are separate applications, while the topics list asp-net-core, csharp and net-mvc alongside cube and newlife. The homepage for the platform is newlifex.com/cube.

Five frameworks, eight databases and one package

The platform support table is where you find out whether this fits your stack, and the answer is broad.

Target frameworks: five in one package, net6.0, net7.0, net8.0, net9.0 and net10.0. Operating systems and architectures: Windows, Linux and macOS, across x64, x86, arm64, arm, loongarch64, riscv64 and s390x. Databases: MySql, SQLite, SqlServer, Oracle, PostgreSql, SqlCe, Access and DM.

That breadth is partly a consequence of how the platform handles persistence. The README states that the database type is detected automatically, with the default being a SQLite file at ../Data/Membership.db, and that MySQL, SQLite, Oracle and SqlCe drivers are downloaded automatically for x86 and x64. So the database list is not a claim of equal support for every engine; it reflects a driver that is fetched at runtime for the platform you are on.

NativeAOT is treated as a first-class concern rather than an afterthought. The README carries an AOT smoke badge pointing at an analysis document in the Doc/ folder, with 18 smoke scenarios for the non-MVC foundation covering JIT and AOT. The AotSmoke/ directory in the repository listing is the corresponding test project.

Localisation is similarly concrete. A badge reports 31 locales, and the Doc/ folder holds a document on multi-language localisation, with scripts named check-locales.ps1 and check-english-messages.ps1 to keep the message catalogues consistent.

From an empty directory to a running admin in four commands

The quick start is short enough to follow exactly. The package comes from NuGet:

dotnet add package NewLife.Cube

The templates do the rest of the work. NewLife.Templates provides the cube and xcode project templates, and the scaffolded projects are built and run like any other .NET project:

dotnet new install NewLife.Templates
dotnet new cube --name CubeWeb
dotnet new xcode --name Zero.Data
cd CubeWeb
dotnet build
start http://localhost:6080
dotnet run

The cube template is the web application with the admin platform wired in, and the xcode template produces the data layer project, named Zero.Data in the example, which is the entity and persistence side. The port in the example is 6080.

If you are on .NET 8 or 9 with minimal hosting, the wiring is visible in six lines:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddCube(); // registers permissions, menus, entity controller scanning
var app = builder.Build();
app.UseMetronic(app.Environment); // or UseAdminLTE / UseTabler ...
app.UseCube(app.Environment);      // routing, static assets and middleware
app.Run();

Three calls do the work. AddCube registers permissions, menus and entity controller scanning. UseMetronic picks a UI theme, with UseAdminLTE and UseTabler named as alternatives. UseCube brings routing, static assets and middleware.

Once it runs, you open the root path to sign in, Swagger serves the APIs, and the standard CRUD endpoints are callable from any front end.

Everything hinges on the Membership connection string

The ASP.NET Core installation path is a list of steps in the README, and one of them carries the whole system.

You create an ASP.NET Core Web project in Visual Studio, reference NewLife.Cube.Core from NuGet or build the source, and then set a connection string named Membership in appsettings.json. The README states plainly what that string is for: users, roles, permissions and menus are stored there. So the platform's own identity data lives in the same database schema it administers, and the connection string name is fixed by convention.

The database type is detected automatically, and the default is Data Source=../Data/Membership.db. Change PluginServer in Config/Core.config if you need a different driver source, and PluginServer in Config/Cube.config if you want scripts and styles fetched from somewhere else. Both plugins are downloaded automatically, which is convenient until you need to run in an environment without outbound network access, or you need to know exactly what is being executed.

Credentials are predictable, which is convenient for a first run and a problem afterwards. The default login is admin/admin, third-party OAuth such as NewLife also works, and the first user created becomes the administrator while the admin account is then disabled.

Publishing has its own list: copy the *.dll files, appsettings.json, the *.deps.json and *.runtimeconfig.json files, and your own assets. A missing runtimeconfig or deps file is the classic reason a published Cube deployment fails to start, and the README tells you to copy both.

The MVC route compiles views into the DLL

The ASP.NET MVC installation path exists for teams who are still on that model, and one instruction sets it apart from the Core path.

The steps are parallel: create an ASP.NET MVC project, reference NewLife.Cube from NuGet or build the source, set a Membership connection string, this time in the connectionStrings section of Web.config, and run it from Visual Studio with View in Browser. The default connection string is the SQLite file with providerName="Sqlite", and the PluginServer settings live in the same Config/Core.config and Config/Cube.config files as in the Core path.

The distinguishing instruction is about view compilation. The README says to install the Razor Generator Visual Studio extension and set it as the custom tool for .cshtml files, which compiles views into the DLL. The consequence is that your views become compiled code in the assembly rather than files read at runtime, so editing a .cshtml file requires a rebuild, and the published output is a DLL rather than a folder of templates.

That single difference decides which path you take. Teams starting a new project on .NET 8 or 9 should follow the minimal hosting route, where the same six lines of AddCube, UseMetronic and UseCube apply and views are not compiled into the assembly by a Visual Studio custom tool. The MVC path is there for existing solutions that are not being moved.

A monorepo of front ends, and an odd release history

The repository is far larger than a single package, and the structure explains the scope.

At the top level sit the core packages, NewLife.Cube/ and NewLife.CubeNC/ for the non-MVC foundation, a dedicated NewLife.Cube.Core, and a long row of front-end packages: Vue, Blazor, Angular, ElementUI, ArcoVue, MUI, Metronic, Metronic8, Tabler, NaiveUI, Shadcn, Svelte, TDesign, Vuetify, LayuiAdmin, AdminLTE and Swagger. Alongside them are the demo applications CubeDemo/ and CubeDemoNC/, the SSO server project CubeSSO/, test projects named NewLife.Cube.Tests, Test, XUnitTest, WebSmoke, E2EMvcTest and AotSmoke, and a Doc/ folder of Chinese-language documentation.

The JavaScript side is a pnpm monorepo. The package.json declares packageManager [email protected] and a private workspace named cube-packages, with shared modules such as @newlifex/api-core, @newlifex/page-utils, @newlifex/field-mapping, @newlifex/auth-logic and @newlifex/page-logic, and a build script per front end. So the front ends are not twenty copies of a template; they share a common API and page layer.

The release history is where the project looks unusual. There is exactly one tagged release, v2.5.2019.0213, described as the core version of cube and dated 2019-02-13, and the numbering follows a year-and-day pattern rather than semver. Yet the repository is not archived and the last push was on 2026-10-20. The NuGet badges at the top of the README point at both a stable and a prerelease version feed, so package consumers get tagged versions, while the GitHub source moves continuously. Anyone pinning a version needs to know which channel they are on, and the README does not document a release policy.

Editorial conclusion

NewLife.Cube fits an ASP.NET Core team that needs an internal admin console over existing tables quickly, and that accepts the platform's conventions, its front-end asset delivery and its NewLife naming in exchange for generated CRUD, permissions, menus and statistics. It is the wrong choice for a public-facing product with bespoke screens, for a team that cannot accept a runtime download of database drivers and scripts from a configurable PluginServer, or for anyone who needs a predictable public release cadence, since the only tagged release is v2.5.2019.0213 from 2019-02-13 while the last push was on 2026-10-20. Before adopting, read the Membership connection string and PluginServer settings in Config/Core.config and Config/Cube.config, and check that the NuGet package version you pull matches the source tree you intend to build.

Frequently asked questions

Official sources

1. License: MIT
2. NewLifeX/NewLife.Cube on GitHub
3. Project website
4. README
5. Releases