DEV Community: Enis Necipoglu

What is 'graphBuild' in .NET CLI & MsBuild

Enis Necipoglu — Tue, 29 Jul 2025 05:14:37 +0000

🚀 Understanding `dotnet build` and When to Reach for `/graphBuild`

You've cloned a large repository. The first clean build works perfectly. But after a few tweaks across indirectly referenced projects, something feels... stale. Welcome to the world of incremental builds — and the subtle fixes offered by graph-based dependency resolution.

🔍 What's the Real Issue?

By default, dotnet build optimizes for speed:

It builds only the project you target.
It includes directly referenced projects, but may not reliably recompile indirect dependencies — especially if outputs exist in bin/obj folders.

This can lead to surprises:

You change ProjectC, which is referenced by ProjectB, but you're building ProjectA (which references ProjectB).
Unless dotnet build detects timestamp or dependency changes perfectly, ProjectC might not be rebuilt.
You silently pick up outdated DLLs — and scratch your head over unexpected behavior.

🧠 Solution: Precompute the Dependency Graph

MSBuild (and by extension, dotnet build) supports the /graphBuild parameter:

dotnet build YourProject.csproj -p:GraphBuild=true

After .NET 5 SDK and MSBuild 16.6 you can even use /graphBuild or even shorter /graph parameter:

dotnet build /graphBuild
# or
dotnet build /graph

This activates static graph mode, ensuring:

Topological build order of all referenced projects (direct and transitive).
Predictable and safe parallel builds.
No reliance on dynamic target evaluation, which can skip certain steps if conditions don’t trigger.

Especially useful in CI/CD, multi-repo, or cross-solution setups.

💡 When Is It Critical?

Use /graphBuild when:

Projects reference others outside their solution.
Conditional build logic or custom targets affect dependencies.
You want to ensure clean transitive builds after codebase changes, even if timestamps aren’t reliable.

🧪 Example

Let’s say you have this structure:

ProjectA
 └── ProjectB
      └── ProjectC

You update ProjectC and run:

dotnet build ProjectA.csproj

Without graphBuild? Might skip rebuilding ProjectC.

With graphBuild?

dotnet build ProjectA.csproj -p:GraphBuild=true
# Or Alt

Guaranteed to build all three in correct order.

🧼 Bonus Tip for Local Builds

After switching branches or making manual edits, do this for a clean, graph-aware rebuild:

dotnet clean ProjectA.csproj
dotnet build ProjectA.csproj -p:GraphBuild=true

✍️ TL;DR

dotnet build defaults to speed over precision.
-p:GraphBuild=true brings back accuracy in dependency chains.
Use it for indirect references, cross-solution setups, or clean builds after changes.

Visual Studio's "Rebuild" vs dotnet CLI — What You Didn't Know

Enis Necipoglu — Tue, 29 Jul 2025 05:00:02 +0000

If you've used both Visual Studio and the dotnet CLI, you might’ve noticed something curious: the CLI has no “rebuild” command. Yet Visual Studio offers “Rebuild” front and center. So what’s going on under the hood?

🔍 What Rebuild Actually Does

Rebuild in Visual Studio is a combination of two steps, executed for each project in the solution:

Clean — Deletes everything in bin and obj, wiping the slate clean.
Build — Compiles the source code from scratch, ignoring any incremental optimizations.

This ensures a full regeneration of binaries, which is useful for resolving weird edge cases, stale references, or flaky builds.

🔄 Isn’t That Just Clean + Build?

Not exactly. The sequencing matters:

Rebuild executes clean + build sequentially per project, respecting project dependencies.
Clean All + Build All might clean everything first, but then build in parallel — potentially leading to race conditions in tightly coupled solutions.

This subtle order of operations makes Visual Studio’s rebuild more predictable in certain scenarios.

🧰 What About dotnet CLI?

The CLI focuses on speed via incremental builds. While there’s no native rebuild, you can mimic the behavior:

dotnet clean
dotnet build

Or script per-project rebuild logic if you need fine control.

✍️ TL;DR

Visual Studio’s rebuild is a smart clean-build sequence per project.
dotnet CLI skips this to prioritize speed and modularity.
Knowing when to use which can save you from hours of puzzling over failed builds.

You do it wrong! Customizing ABP Login Page Correctly

Enis Necipoglu — Tue, 27 May 2025 08:19:56 +0000

One of the most frequently asked questions within the ABP Community is:

How do I change the login page?

The answer often seems simple, but is it always the correct or most suitable approach for your specific needs? Let's delve into the details. This article will guide you through the recommended ways to customize the login page in the ABP Framework, highlighting a common misunderstanding and ensuring you modify the right components.

Understanding the ABP Login Page

ABP Framework templates include default login functionality provided by the Account Module. When you want to alter the appearance of the login screen, your first thought might be to override components directly from the Account Module. While this seems straightforward, is it what you truly need to achieve?

Customizing the Login Page or the Account Layout? That's the Question.

In many scenarios, what developers aim to customize is actually the Account Layout, not the core Login Page component itself. It's a subtle but important distinction.

Consider the following diagram illustrating the relationship between the Login Page and the Account Layout:

Login Page: This refers specifically to the area containing the login form (e.g., username/email and password fields, login button, "forgot password" link).
Account Layout: This encompasses the broader structure surrounding the login form. It includes elements like the header, footer, branding (logo), background, and overall page styling that frames the login form.

Often, your customization goals—such as changing the logo, background color, or the overall page structure around the form—are better addressed by modifying the Account Layout. In fact, you might not need to override any C# or Razor components at all; simple CSS adjustments might suffice.

This leads to three primary customization options, ordered by complexity and impact:

Use CSS classes to customize the page.
Override the Account Layout component.
Override the Login Page component (from the Account module).

Let's explore each of these.

1. Customizing with CSS Classes

Each ABP theme (like Basic or LeptonX) applies a specific CSS class to the <body> element of its layouts. This is a powerful feature, as it allows you to scope your CSS customizations effectively, even when adding styles to a global file like global-styles.css.

Here’s how these layout-specific classes typically appear in the rendered HTML

Application Layout

Account Layout

By leveraging these classes, you can write targeted CSS rules that only affect elements within the account layout (or any other specific layout).

Here's a practical example of how you might customize the account layout's appearance:

/* For the Basic Theme */
.abp-account-layout 
{
    background:rgb(203, 196, 196); /* slightly reddish white */
}
/* Or if you're using LeptonX theme */
.lpx-login-bg {
    background-image: none !important;
    background:rgb(203, 196, 196); /* slightly reddish white */
}

/* Account Login Card */
.abp-account-layout .card {
    background-color:rgb(42, 42, 42); /* dark gray */
    color: white;
    width: 480px; /* Do not change this width like this static value. It's a demo value. */
}

.lpx-login-title {
    color: white;
}
/* Account Login Card End */


/* Bootstrap Buttons in Account Layout */
.abp-account-layout .btn-primary {
    background-color:red;
    border-color:red;
    color: white;
    font-weight: bold;
}

.abp-account-layout .btn-primary:hover {
    background-color:red;
    border-color:red;
    color: white;
}

.abp-account-layout .btn-outline-primary {
    color: red;
    text-decoration: none;
    border-color: red;
}

.abp-account-layout .btn-outline-primary:hover {
    color: white;
    background-color: red;
    text-decoration: none;
    border-color: red;
}

.abp-account-layout a {
    color: red;
}

Applying such CSS can significantly alter the look and feel, as shown below:

This CSS-first approach is often the cleanest and easiest way to achieve visual customizations.

2. Overriding the Account Layout Component

If CSS customizations aren't sufficient to meet your structural or more complex visual requirements (e.g., adding new sections, significantly reordering elements around the login form), your next step might be to override the Account Layout component itself.

The exact steps for this depend on the ABP theme you are using:

For the Basic Theme: The original Account.cshtml layout file is open-source and its content can be found directly in the ABP Framework GitHub repository:
- /Themes/Basic/Layouts/Account.cshtml
For Commercial Themes (like LeptonX Theme): You'll first need to obtain the theme's source code. You can do this using the ABP CLI command:
```
abp get-source Volo.Abp.LeptonXTheme
```
(Or the equivalent package name for the specific theme/version you are using))

Once you have access to the original layout file's content (either from GitHub or the get-source command), you can override it by creating a file at the corresponding path in your web project:

Basic Theme location: /Themes/Basic/Layouts/Account.cshtml

📂YourProjectName.Web
└── 📂Themes
------└── 📂Basic
------------└── 📂Layouts
------------------└── 📄Account.cshtml
LeptonX Theme location: /Themes/LeptonX/Layouts/Account/Default.cshtml

📂 YourProjectName.Web
└── 📂 Theming
-------└── 📂 LeptonX
-----------└── 📂 Layouts
----------------└── 📂 Account
---------------------└── 📄 Default.cshtml

(Always refer to the theme's documentation or source structure for the exact override path.)

By placing your custom Account.cshtml (or Default.cshtml for LeptonX) file in these locations, the ABP Framework will use your version instead of the default one. This approach grants you full control to modify the HTML structure of the Account Layout as needed, allowing you to add, remove, or rearrange any content surrounding the core login form.

3. Overriding the Login Page Component

This option involves changing the actual login form itself (the Login.cshtml page from the Account Module) and should generally be your last resort, used only when you need to alter the form's internal structure, add new form fields, or change its core behavior in a way that CSS or Layout overrides cannot achieve.

The login page, with its core form elements and logic, originates from the Volo.Abp.Account.Web module. You can override this specific component by creating a new Login.cshtml file (and its corresponding Login.cshtml.cs PageModel if you need to alter the C# logic) in the Pages/Account folder of your web project.

The original content for the Login.cshtml page can be found in the Account Module's source code on GitHub:

/Modules/Account/Pages/Login.cshtml

To override it:

1) Create the following folder structure in your .Web project if it doesn't already exist.
2) Create a Login.cshtml file inside this Account folder.

📂 YourProjectName.Web
└── 📂 Pages
------└── 📂 Account
------------└── 📄 Login.cshtml
3) Copy the content of the Login.cshtml page and paste it to your new Login.cshtml file.
4) Modify these files as needed. You can now change input fields, add new elements directly to the form, or adjust the server-side handling in the PageModel.

Remember that overriding the Login.cshtml page directly makes you responsible for maintaining compatibility with future updates to the Account Module, as its internal structure or logic might change.

Conclusion: Customize Smartly

Customizing the login experience in ABP Framework is flexible, but it's vital to choose the right approach. Before diving into component overrides, ask yourself:

What exactly do I want to change? Is it the overall look and feel (branding, colors, background) or the structure of the login form itself?
Can this be achieved with CSS? Often, targeted CSS rules leveraging theme-specific layout classes are sufficient and the least intrusive method. This should be your first consideration for visual tweaks.
Do I need to alter the content around the login form? If yes, overriding the Account Layout (e.g., Themes/Basic/Layouts/Account.cshtml or its LeptonX equivalent) is the correct approach. This gives you control over headers, footers, and surrounding content without touching the core login mechanism.
Do I need to change the login form fields or its core submission logic? Only then should you consider overriding the Login Page component itself (e.g., Pages/Account/Login.cshtml) from the Account Module.

By understanding the distinction between the Account Layout and the Login Page component, you can implement customizations more efficiently, maintainably, and align with the framework's design principles. Start with CSS, then consider Account Layout overrides, and reserve Login Page component overrides for when they are truly necessary. This will save you time and make your application easier to upgrade in the long run.

DEV Community: Enis Necipoglu

What is 'graphBuild' in .NET CLI & MsBuild

🚀 Understanding dotnet build and When to Reach for /graphBuild

🔍 What's the Real Issue?

🧠 Solution: Precompute the Dependency Graph

💡 When Is It Critical?

🧪 Example

🧼 Bonus Tip for Local Builds

✍️ TL;DR

Visual Studio's "Rebuild" vs dotnet CLI — What You Didn't Know

🔍 What Rebuild Actually Does

🔄 Isn’t That Just Clean + Build?

🧰 What About dotnet CLI?

✍️ TL;DR

You do it wrong! Customizing ABP Login Page Correctly

Understanding the ABP Login Page

Customizing the Login Page or the Account Layout? That's the Question.

1. Customizing with CSS Classes

2. Overriding the Account Layout Component

3. Overriding the Login Page Component

Conclusion: Customize Smartly

🚀 Understanding `dotnet build` and When to Reach for `/graphBuild`