Skip to content
alikhan.tech

Writing

Angular / .NET Core Heads on XM Cloud — When Next.js Isn’t the Only Option

Muhammad Ali Khan · 08 Nov 2026 · 07 Mins read

Angular / .NET Core Heads on XM Cloud — When Next.js Isn’t the Only Option

Every SitecoreAI starter conversation I sit in begins with Next.js, and for a team that already lives in React that is the right beginning. It is a bad beginning for the team that has an Angular design system they are not going to rewrite, or a stack of ASP.NET Core services they expect the public site to join. I have watched both teams lose a quarter trying to become a Next.js shop because the demo was a Next.js shop. The product is a headless CMS with a published layout model. The head is allowed to be something else, as long as we are honest about which SDK Sitecore is actually maintaining for that runtime and what "editing" costs.

By 9 November 2026 the honest list is shorter than the historical JSS language list and longer than "Next.js only." Content SDK for Angular 1.0 went generally available on 10 September 2026. The ASP.NET Core SDK is documented against SitecoreAI and against XM/XP, and it deploys beside the SaaS product rather than inside it. This is how I choose.

Angular is a first-class Content SDK target now

The September changelog is specific, which is the only reason I am willing to recommend it for a new build. Content SDK for Angular 1.0 supports the core SitecoreAI authoring and delivery path: server-side rendering, loaders for route data, field rendering including an scImage directive, Pages editing and preview, internationalization, multisite, analytics, personalization, and deployment as an editing host. The GA added things the beta was not ready for me to bet a launch on. Bot-aware tracking records a single server-side page view for a crawler and skips personalization so bots do not pollute CDP. Loader results cache through unstorage, with a /api/revalidate endpoint that understands tags, including tags coming from an Edge webhook. Redirects middleware runs before personalization. Analytics and personalization are plugins with adapters, so a team that cannot use the default visitor cookie has a documented place to replace it.

The scaffold is the same package the Next.js teams already use, with a different template:

npx create-content-sdk-app@latest angular --destination ./web --yes

The sample app Sitecore describes is Angular 21, wired to the Skate Park reference site. I treat that sample the way I treat the Next.js starter. It is a donor of working wiring. It is not a design system, and I do not spend a sprint arguing with its CSS.

The connection variables are not the Next.js names. Angular's getting-started page asks for SITECORE_EDGE_CONTEXT_ID, CSDK_PUBLIC_SITECORE_EDGE_CONTEXT_ID, and CSDK_PUBLIC_DEFAULT_SITE_NAME, through the environment or through sitecore.config.ts. I keep the public ones public and the editing secret on the server, same rule as the Next app. Mixing NEXT_PUBLIC_SITECORE_EDGE_CONTEXT_ID into an Angular host because a wiki was copied from the other repo is the first defect I look for when preview works on one app and not the other.

Editing still means the page builder, metadata on the fields, and an editing host Sitecore can reach. It does not mean Experience Editor. A team moving an older JSS Angular app should expect the same class of chrome removal I described for Next.js at the end of October. I do not run a dual-SDK plan where new components are Content SDK Angular and old ones stay on JSS inside one rendering host. One host, one SDK, a component map or its Angular equivalent that the build generates.

Personalization being "included" does not exempt this head from the caching rules I wrote for Next. A component-level test still has to render the variant the middleware selected. If the Express layer in front of Angular caches HTML without the variant, the test is fiction in a different language. The bot middleware skipping personalization is a gift. I do not undo it to make a crawler screenshot match a marketer's variant.

.NET Core is supported beside SitecoreAI, not inside it

The ASP.NET Core SDK is the path I recommend when the team writes C# and wants model-bound views over layout JSON. Sitecore's docs describe it as open source, able to front SitecoreAI or XM/XP, retrieving layout data and binding it onto views, view components, partials, and tag helpers. Middleware maps the incoming HTTP request onto an Experience Edge request. Localization, sitemaps, and redirects are part of the documented task list. The starter kit is the XM Cloud ASP.NET Core starter, and I start there rather than from an empty web SDK project plus a blog.

The constraint that decides the architecture is in the same document. An ASP.NET Core app built with this SDK is not deployed inside SitecoreAI. You host it yourself, Azure App Service being the example they give, and you configure an external editing host so the page builder uses your deployment to render editing chrome. There is no "add this project to the SitecoreAI rendering host slot" step. Budget a hostname, a certificate, and a network path from Sitecore's editing infrastructure to that host. If that path is IP-restricted, editing will fail while the public site works, and you will lose a day blaming the SDK.

The docs also still tell JavaScript teams to use JSS, in a sentence that predates the Content SDK lifecycle note. I do not follow that sentence for a new SitecoreAI build. JavaScript heads go to Content SDK, Next.js or Angular. .NET heads go to the ASP.NET Core SDK. JSS remains the relevant history for an XM/XP solution on a version that never moved to SitecoreAI. I say that out loud because a solution architect will find the JSS sentence and add a second head "for the React widgets" in the same solution. Two heads are allowed. Two SDKs accidentally editing one site are not.

A page model in this stack is boring C#, and that is the point:

public class ProductHeroModel
{
    public string Heading { get; set; } = "";
    public string Summary { get; set; } = "";
    public string ImageUrl { get; set; } = "";
}

The SDK's model binding and tag helpers are what connect Heading to the layout JSON field. I take the helper syntax from the starter we generated, not from a 2019 Rendering Engine sample, because Sitecore's compatibility table now distinguishes the ASP.NET Core SDK from the legacy ASP.NET Core Rendering SDK. Mixing those namespaces compiles for a while and then fails in editing. The view stays a view. Business calls that need a product API live in a view component or in a service the view component calls, not in a helper that re-fetches layout data the middleware already fetched.

How I choose, in the room, without a framework argument

I ask three questions.

Who will maintain the rendering host in two years, and in what language do they already ship production code? A team of Angular developers with a library of accessible components should take Content SDK for Angular 1.0. A team of C# developers who run the rest of the estate on ASP.NET Core should take the ASP.NET Core SDK and an external host. A team with no front-end specialists, adopting SitecoreAI as a new platform, should take the Next.js Content SDK, because that is the combination the rest of the current guides assume, including the upgrade guides I walked through on 29 October.

Does the page builder have to show this component before the public site deploys? All three paths can do editing. Next and Angular can be the editing host Sitecore deploys or a local host the selector points at. .NET is always an external editing host you operate. If the organization cannot run that host, I do not pick .NET for the public rendering tier. I might still pick .NET for a separate integration service that never renders a page.

Are we personalizing at the component level, and where is HTML cached? The answer has to be "we know" before I care which language renders the markup. Edge publishes variants. The head and the CDN have to honor them. Angular's new revalidation endpoint is enough to keep ISR-style caching honest if we point the Edge webhook at it. A .NET host needs the equivalent policy on its output cache. Next.js is not magically safer. It is just the one I have already written the webhook notes for.

What I stop promising

I stop promising that every JSS sample in Angular from 2022 compiles against Content SDK 1.0. The field metadata model changed, and the editing endpoints changed. I stop promising that a .NET Framework MVC solution "is basically the same" as the ASP.NET Core SDK. It is not, and XM Cloud was never going to host it. I stop promising feature parity down to every Next.js 16 helper. Angular 1.0's changelog is the list I will defend: SSR, editing, personalization, redirects, bot handling, tagged revalidation. A helper that exists only in the Next package is a Next helper. We reimplement the behavior or we drop it.

I also stop using the word "headless" as if it means "bring any frontend and Sitecore will not care." Sitecore cares at editing time. The page builder has to reach a host that understands its metadata protocol. A hand-rolled SPA that only calls the GraphQL endpoint for published content can be a fine delivery app and a terrible editing app. If authors need to see the component while they type, we use the SDK.

The sequence when Next.js loses the argument

  1. Write down the language the team will still know how to hire for, and pick Angular Content SDK 1.0 or the ASP.NET Core SDK from that, not from the demo.
  2. Scaffold the official starter. Connect it to a non-production SitecoreAI environment with that SDK's variable names. Prove a published route renders.
  3. Prove editing. For Angular, local host or the deployed editing host, metadata visible, save and preview. For .NET, an external editing host Sitecore can reach, then the same save and preview.
  4. Add one real component from the existing design system or view library. Do not port the starter's sample components into production styling.
  5. Attach caching and personalization rules before the first experiment. Bots out of the test. Variants out of any cache that ignores them.

Next.js remains the path I recommend when there is no incumbent. It is not a requirement of the CMS. The requirement is a maintained SDK, an editing host the page builder can call, and a team that can own the process after I am gone. Angular has that SDK as a GA release. .NET has it as an external host. Both are real options in November 2026, and I would rather start on the one the team can finish.

Related notes